5 ms·

"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. " T

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

edw519 18y ago
...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.
- nonrecursive 18y ago
  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.
  - edw519 18y ago
    Yegge is criticizing an accepted definition of requirements analysis So his title (Business Requirements are Bullshit) was just bait. I guess I took it. I once wrote a hn post with a lot more "meat on the bones" about what works. Here it is: http://news.ycombinator.com/item?id=84977 http://news.ycombinator.com/item?id=84977
    - swombat 18y ago
      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.

edw519 18y ago

...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.

nonrecursive 18y ago
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.
- edw519 18y ago
  Yegge is criticizing an accepted definition of requirements analysis So his title (Business Requirements are Bullshit) was just bait. I guess I took it. I once wrote a hn post with a lot more "meat on the bones" about what works. Here it is: http://news.ycombinator.com/item?id=84977 http://news.ycombinator.com/item?id=84977
  - swombat 18y ago
    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.