"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. :-)
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.