I have read Steve's articles before with a certain amount of respect, but this time he addresses an area very near and dear to me, and all I can say about this one is:
I call bullshit.
This article was so full of it, the more I read, the more I had to change into higher waders.
As I normally do when responding to a post, I started pulling out the statements I wanted to respond to, highlighting them, and putting my response below. After 10 minutes, I had the Magna Carta. This is simply too much wrong with this article to respond in the usual way.
So instead, I'll just say this...
Get this and get this good, fellow hackers: When anyone says "analysis" or "requirements gathering" is bullshit, there can only be one reason why: they don't know how to do it.
Sure, there are antecdotes and case studies of people building great software without talking to users first, but they are in the extreme minority, and anyone proposing doing this all the time is doing a disservice to his readers.
In order to find out what people need from software, you don't "grill" them, "interview" them, or "role play" (whatever that means). You get with them and "live their lives" and suffer with them, understanding what they must accomplish, how they must do it, and what's stopping them now. How do you do this? Any way you can. Change uniforms and shovel shit with them. Do their job for a day. Put them together in a room, feed them, give them beer (optional), and get them to bitch about it. Identify every single data element related to their tasks. Connect tasks and data to objectives (You may find that half of what they already do is a waste of time.)
In short, do whatever it takes to find out what you need to know to develop your software. This is hard work. Hardly anyone does it now, and relatively few have ever done it. Steve Yegge certainly hasn't. If he had, the data in this rant would have been very different.
Sorry, Steve, I normally enjoy your columns. Do us all a favor and don't say something can't be done because you've never done it. Next time, write about something you've already done. Then we can all resume learning from you again.
"You get with them and "live their lives" and suffer with them, understanding what they must accomplish, how they must do it, and what's stopping them now. "
This is a great idea, and the real way to address the problem Steve suggests: Become the business.
However, the majority of your criticism of Steve is way off base, because the methods he describes are not strawmen, but the actual methods described in most of the software engineering requirements books. If you look at Karl Wiegers book, Software Requirements, which is considered by many to be a leading reference on the subject, it describes a process much like the one Yegge criticizes.
...actual methods described in most of the software engineering requirements books...
Thank you, Matt. You have just demonstrated my number one concern about the nature of discourse here on hacker news. The issue of "book contents" vs. real world experience.
I don't know you and certainly don't mean to pick on you, but calling my criticism of Steve's article "way off base" merits this response...
First a little of my background. Even though I've been a hacker my entire professional life, I had the good fortune to be mentored by an industrial engineer from a user department. He did one thing extrememly well and taught me how to do it: solve business problems to make money. This is the stuff that is rarely taught in any book, much less one that is "considered by many to be a leading reference on the subject".
Shocking as it may seem, many books on business systems and IT offer very little and many are simply wrong.
I have not read Karl Wieger's book and feel out of place evaluating it. However, I did read the synopsis and all 45 reviews on Amazon. Nowhere did I see mention of any of the things from my OP that I know work every time. Instead I saw lots of mention of techniques like rational rose, entity-relationship diagrams, use cases, and modeling. As anyone who has successfully conducted analysis will tell you, these techniques were never actually designed to achieve results; their purpose is to control the people and the process, not the outcome.
I stand by my original criticism of Steve's article. He is dead wrong about analysis. He doesn't respect it, probably because he doesn't know how to do it. Your comment makes me wonder if the same holds true for you.
Part of the problem is that talking about the analysis process is like writing a textbook on romance. How do you fall in love? Is there a set of best practices and a six-sigma process? Well, no. It's an art. It depends entirely on the situation and on the parties involved. You get better at it with practice. There are rules of thumb that are definitely helpful, but you have to know when to break them. Unfortunately, there's also a great deal at stake: If you screw it up it can ruin your life, but if you get it right you can be happy for decades.
The literature on the subject tends to gravitate towards formal techniques: Dance instruction, sex education, grooming, fashion. Not so much because these are the essence of romance, but because they're much easier to describe in print. And because the people who turn to books are not the ones whose relationships are going well, but the ones who need help -- and when the going gets tough, formalism can be a very useful tool. Nobody consults a lawyer on a first date, but when you need a divorce formal procedures come in really handy.
"How do you fall in love? Is there a set of best practices and a six-sigma process?"
I don't know, but "The Six-sigma Process for Romance; Taking the Guesswork out of Finding Love" sounds like the title of a New York Times Bestseller to me.
Seven-Sigma dating. It's like six sigma only we don't know what we're talking about.
I'm with several of the commenters. There's a big difference between books and reality. I'm not going as far as edw with his "modeling controls the discussion" (e-gads! Get this man a UML primer and be quick about it!) but there's a long, long way from a guy peddling a book to a guy you'd actually want helping you to do anything.
I'm not throwing books out. Not by any means. Lots of my friends have written software books and I'm peddling one myself nowadays. Got a bookcase full of some good and some not-so-good books. But it's a medium, and the medium has its quirks.
I think that mattmcnight's point was that Yegge is criticizing an accepted definition of requirements analysis. So, edw, when you say "he doesn't respect it, probably because he doesn't know how to do it" you are a bit off base - you're referring to a practice which is different from the one matt and Yegge are talking about. But you're probably right that they aren't familiar with the kind of requirements analysis you're talking about. It also seems like you're agreeing with them when they say that "requirements analysis is bullshit" - because you think the practices they're referring to are worthless.
That said, I am very interested in the things that you know work every time. I'm sure I'm not the only one.
Of course his title was bait! What else could a title like that be!? :-)
I also think that your response is off-base though. Taking your own statements:
1) Steve is wrong to call "Requirements gathering" bullshit because you know how to do it properly
2) "Requirements gathering" as taught in most accepted books and other texts is bullshit
If you then throw in:
3) Steve was referring to the "Requirements agethering" as taught in most accepted texts (and, I'll add, practiced in many large organisations).
Then we get:
4) You're referring to your own special brew of "Requirements gathering", which has little to do with what Steve was talking about!
Unfortunately, when most people say "Requirements gathering", they refer to the standard, accepted processes taught in books and large consulting companies. And those, as Steve declares, are largely bullshit. I worked in a large, process-driven IT consulting firm for 4 years, and I can affirm without a doubt that the processes they used to gather requirements would fail miserably at attempting to produce a great start-up product.
I think Yegge goes beyond that, though. He presents "make something you, yourself, want" as the key to making something others want. If I understand edw519 correctly, he is saying "bust your butt and do a lot of very hard work to see the world through your customers eyes," in order to to make something others want.
'Make something you yourself want' is what I would recommend to hackers in general.
No offense to them, but when it comes to understanding what others want, they aren't able to do it, and often lament, criticize, put down, or devalue other people's actions or responses that don't make sense (instead of trying to understand them). For instance, many hackers can't fathom why so many people use Facebook (and don't try to understand that target population, but just ignore it or write a blog post about how Facebook has no value to them).
If you have the ability (and I really think it is a skill that you have to train) to understand other people and their motivations and needs, then I would suggest doing what edw is saying. But, from experience trying to teach my own hacker friends, this ability is very hard to learn.
Unfortunately for hackers, making what they themselves want often only caters to a small niche market in the vast world of people out there, so it might be useful to invest some time in learning how to understand other people, or team up with someone who has that ability in one form or the other.
The "business requirements gathering" Yegge is railing against isn't just book knowledge, it is standard operating procedure at most "consultancy" type shops. Even large product firms and small product startups do it. He gives an example of doing it at HP.
Again, I don't think he or I are criticizing what you're talking about when we would say business requirements are BS. Steve probably agrees with you. His target audience is the people attempting to learn what is, unfortunately, standard industry practice. I have had the misfortune to work on projects with 3 layers of requirements analysis between developer and user. What you, me, Steve and fortunately most of the hackers here know is that communicating requirements via any form of written documentation is necessarily inferior to richer forms of communication and deeper levels of understanding. Sadly for the socialists, it puts many requirements analysts, a job for which I can't seem to find anyone who would be considered unqualified, out of work. :-)
Based on your comment, you basically agree with Steve's argument. You agree with him that "grilling" and "role playing" don't work. This is precisely what he meant. He then goes on to argue that people should build products that they want for themselves. You want people who build products to "live [their users'] lives" in order to understand the users' tasks. Sounds quite similar to me.
"In short, do whatever it takes to find out what you need to know to develop your software. This is hard work. Hardly anyone does it now, and relatively few have ever done it. Steve Yegge certainly hasn't"
For me, the point Steve makes is that the optimum is to build for yourself. The feedback loop is instant. That's where the best software gets written. When developers wake up at 3am with some idea for a feature that would make the software they want, work better.
If you're trying to write software for others, it's going to end up as mediocre and probably not entirely what they wanted.
If you're trying to write software for others, it's going to end up as mediocre and probably not entirely what they wanted.
Stop for a minute and notice how absurd this statement is.
99.9% of all software ever written was for others. Was it all mediocre and "not entirely what they wanted"?
This is the entire reason for systems analysis and requirements specification. You don't need to do any of this for the software you're writing for yourself. You must do all of it and do it well when writing software for others; that's how you insure that it's exactly what they want.
99.9% of all software ever written was for others. Was it all mediocre and "not entirely what they wanted"?
Having lived and breathed (and somehow survived) in the enterprise environment that employs the vast majority of the programmers out there, I can agree with that proposition whole-heartedly.
Yes, 99.9% of the software that gets written is mediocre at best. A shockingly large proportion of it is downright abysmal, but most of it is mediocre. Thankfully, we don't get to see most of that software since it is safely locked away inside the mega-corporations that pay hordes of programmers to write it.
99.9%? That's just insane. You're saying that all the games developers never play their own games?
How about people writing languages, compilers etc. You don't think they use them??
I'd say the majority of open source software is written for yourself rather than others. People contribute the most when they are using that software.
You don't have to be the only customer/user of your software, but it helps to be a customer/user of your own software. That's what I mean by writing for yourself.
I'm saying that the ERP, accounting, banking, claims processing, ecommerce, order entry, scientific, etc., etc., etc. software they work on is for someone else. They dwarf those working on games, compilers, and open source.
I think there's a difference between an engineer working for someone, and the person making the product decision. If you're a developer for a software company building accounting software, and you don't have much use for accounting software personally, you're probably fine. But if you're defining the product, you're much better off if you've been a user of accounting software in the past.
I interpret the post as just a long rantish way of saying: "If you want to write good software, you've also got to use it."
In my experience, there is a lot of software out there that is deemed valuable by management, produces good ROI, but is despised in some way by its users. I'd say the majority of it. (And I've been in many dozens of shops as a consultant.) That will fly for internal software for a big company, but not for a web startup.
Another way of saying it: really doing "systems analysis and requirements" right puts you in the user's shoes. That's the part that matters, not the artifacts produced by the process. (I'm preaching to the choir here, I know.) In fact, the "systems analysis and requirements" process matters not a bit, only the result, which should be getting the real user experience into the heads of development.
1) Pick an area that most newbies don't get (ie, requirements)
2) Blather on for a while about all the ways they are done wrong
3) Miss the point of the topic. In requirements, you list what you do, then do it. Instead confuse key terms, like "user" and "customer", or "grill" with "be immersed in"
4) Try to be funny
5) Make sweeping conclusions that are obviously incomplete in the real world "Code only for yourself" -- so everybody with a need now has to have a programmer with the same exact need? Wow.
6) Throw in some generally accepted wisdom ("find something good and take stuff out") as a way of tossing the crowd a bone
7) Profit!
As a general rule of thumb, if somebody comes to you with a common phrase from software engineering and makes a sweeping statement (a friend just blogged "reviews are worthless!") then they are either pulling your leg a little bit or don't know what the heck they are talking about. The usual method of attack is to describe how something is commonly done and then disparage the concept by way of association.
If you don't eat their sandwiches, then you'd better have a LOT of friends who eat them every day, or you're breaking the cardinal rule
The point of that long winded article is don't build something unless you are going to use the product or personaly know a lot of people who will. Never ask people you don't know what they want it's stupid. Take the segway it's cool but it's clearly something people want in the abstract even if it's not useful 99% of the time which is the type of thing you build when you ask people what they want without having any idea what you want to build.
An example of the opposite as a datapoint: We've all eaten institutional food cooked by people who are following a recipe they may not particularly care a whole lot about and probably won't eat their own cooking.
We are developers so I think the question is the rate of adoption of new recipe's at McDonalds? They are spending money on new recipe's and advertising them etc but how many of there new ideas catch and are still in use in 5-10 years? And how many of the successes are based on what someone wants to eat vs. what they think other people might buy.
At a previous job, I was tasked with automating an industry that had not seen much automation at all. I was told that we had someone in-house who "knew the industry" and "could be used as a resource", but this person was only ever on one side of the transaction, and that side wasn't the majority of the process we were trying to automate (it was like trying to computerize a retail checkout process and your "expert" was someone who had only ever waited in line to pay).
When I said I'd like at least a month to actually go and do the jobs of the people and companies in the target demographic, I was told we didn't have time for that.
I call bullshit.
This article was so full of it, the more I read, the more I had to change into higher waders.
As I normally do when responding to a post, I started pulling out the statements I wanted to respond to, highlighting them, and putting my response below. After 10 minutes, I had the Magna Carta. This is simply too much wrong with this article to respond in the usual way.
So instead, I'll just say this...
Get this and get this good, fellow hackers: When anyone says "analysis" or "requirements gathering" is bullshit, there can only be one reason why: they don't know how to do it.
Sure, there are antecdotes and case studies of people building great software without talking to users first, but they are in the extreme minority, and anyone proposing doing this all the time is doing a disservice to his readers.
In order to find out what people need from software, you don't "grill" them, "interview" them, or "role play" (whatever that means). You get with them and "live their lives" and suffer with them, understanding what they must accomplish, how they must do it, and what's stopping them now. How do you do this? Any way you can. Change uniforms and shovel shit with them. Do their job for a day. Put them together in a room, feed them, give them beer (optional), and get them to bitch about it. Identify every single data element related to their tasks. Connect tasks and data to objectives (You may find that half of what they already do is a waste of time.)
In short, do whatever it takes to find out what you need to know to develop your software. This is hard work. Hardly anyone does it now, and relatively few have ever done it. Steve Yegge certainly hasn't. If he had, the data in this rant would have been very different.
Sorry, Steve, I normally enjoy your columns. Do us all a favor and don't say something can't be done because you've never done it. Next time, write about something you've already done. Then we can all resume learning from you again.