Business Requirements are Bullshit

this (http://kerneltrap.org/node/5725) is soo much better.

More succinct, yes, interesting too, but I'd disagree with "better." It's like saying an apple is better than an orange.

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.

One of the biggest, most consistent problems I saw as a Smalltalk consultant was simply poor communication between development and users. There were inevitably at least two groups or levels of management in the same group between the users and development. The result was always the game of "telephone" or "gossip" -- the one where you form a line and one person whispers a message to the next. Information, filtered through too many minds always gets distorted in the process.

I think you can do requirements gathering. But the right way to do it is to have smart actual users talking directly to smart actual devs. Even here, there is a chance for misunderstanding, but at least it's not compounded. (I suspect that the "telephone" game is an example of a nonlinear exponential process.)

Unfortunately, middle managers defending their personal fiefdom will sometimes actually tell you that it's specifically not going to happen. In large organizations, upper management generally wants their representative to be the filter between the devs and the users, because software is generally an instrument of control. (Through workflow, even if the app has no explicit workflow framework, but that's another story.)

Often in large organizations with a software project, devs and users will find some way to get together and talk face to face. It's a sign.

We, the hoi polloi developers, work for industries (retail, transportation, insurance, etc.) we hopefully know some thing about, yet without having the same level of expertise (or even the same point of view) as our customers.

He should get himself familiar with the concept of division of labor...