Business Requirements are Bullshit

I find that a lot of Free Software is terrific for exactly this reason — the authors built it for themselves. Their software works for me too because I am very much like them, and if it's not quite right I'll send an email with a patch + diatribe.

The recent fracas over 'usability' in Open Source Software shows that a lot of hangers-on still don't get it. The last thing the community needs is more middlemen: affected 'designers', managers, marketers.

No, that's confusing usability with requirements. To stretch the investing analogy perhaps too far, you should only invest in what you know, but you should let the financial experts tell you if the terms of the investment vehicle are bad.

It's a narrow but important distinction: lots of other people may have the exact same need you do. But it's an unjustified assumption that therefore their brains work exactly the same way as yours and (for example) have no problem remembering your idiosyncratic obscure command-line option syntax.

Thank you for a good portion of laugh and brainfood! :)

Buy this stuff now! It dissolves dog poop. I think I would pay for something that made baby poop not stink. Or maybe stink less.

Your article reminds me of 37signals..

I have HP-15C and HP-16C emulators on my iPod Touch. They sounded cool when I saw them on the jailbreak app list.

I've had the thing for two months, and I've never used those HP calculators.

How did Rock Shox get the cool as the seat extender lost? Now it's difficult to find a decent bike that doesn't go bouncy bouncy...

And this is why every developer who strikes out on his/her own for the first time decides that what the world really needs is either (1) source control or (2) bug tracking.

But it's an unjustified assumption that therefore their brains work exactly the same way as yours

Assuming that other people's brains work differently than your own, and tailoring your work to the model that self-styled 'usablitly experts' imagine they have is even more unjustified.

If you write it for yourself it's perfectly usable for at least one person, and if like the rest of us you're not unique, it's going to be great for a lot of people. If you're writing it for a pretend user, it can easily be perfect only for someone who doesn't exist.



have no problem remembering your idiosyncratic obscure command-line option syntax.

This trope is getting old, and furthermore it's unclear whether you:

a) Are incapable of using CLIs, unwilling to read a paragraph of of documentation, intolerant of a non-flat learning curve, totally dependent on wizards and menu-grazing — ruminant computing.

- or -

b) Have strongly-held beliefs about short vs. long options, whether -- for long options is preferable to -, the use of a solitary -- as an option terminator, the balance of interactivity, the charms of getopts and readline packages, the importance of letting the shell do it's job, --help vs. man vs. info vs. html — enlightened crankiness.

@ bladself: "If you write it for yourself it's perfectly usable for at least one person"

This assumes an uncomplicated relationship between your observations of yourself and reality.

In fact, people convince themselves all the time that they've created something perfectly usable when in fact they're wasting time and driving themselves crazy.

Or at any rate, I know that I'M not a very reliable observer of my own self. But perhaps I'm making an unjustified assumption there.

Assuming that other people's brains work differently than your own, and tailoring your work to the model that self-styled 'usablitly experts' imagine they have is even more unjustified.

Well, actually, no. Usability can be objectively analyzed and evaluated, and developers are notoriously bad at it.

But that's not really the point I was trying to make. Steve's post is not really about software construction, but about requirements, and you conflated the two. Building a tool that meets a need you have is one thing. Making that tool easy-to-use for a lot of other people who have the same need is a different discipline.

The problem with everyone eating their own dogfood is that there will always be some class of people with product needs that cannot make dogfood. Who speaks for them?

Usability in open source projects is a real problem, since nobody incapable of building software themselves will be able to use it. You may not care as a software snob. You may even call these people idiots. But you can't deny that there's unmet market need.

The real key is the the presence of the really talented designer (a la Steve Jobs) that can actually step into someone else's mind and figure out what they want. As of right now, this process is magic; hell, we call it "taste". Steve is right that interrogating potential customers to gather business requirements doesn't work for this purpose. (See Malcolm Gladwell's Blink.) However, saying that we shouldn't even try is wrong. We need to do the work to distill "taste" into craft, and then into engineering discipline.

One thing missing about the 1994-iPhone: it needs a decent keypad. My phone technically does everything listed, but I only use it as a calculator and phone, because 10 keys just aren't enough for text.

Most software developers (like me) are in-house programmers that develop products for other people. We can't all quit our jobs to start companies like 37Signals because... well... we are needed! Sure, we are unappreciated and underpaid, but we are soooo in demand!

It's like that movie where all the Mexicans disappear from California overnight and the state basically screeches to a halt.

Anyway...

I think the solution for us is to actually get to know our "customers" and work with them, using their software. Basically, we need to eat our own dog food. Only then can you really build something for yourself.

…there will always be some class of people with product needs that cannot make dogfood. Who speaks for them?

Nobody is, and noone ever will. Using 'user stories' and the like is just pretending, writing software for a lie. At least writing software for yourself is honest.


The real key is the the presence of the really talented designer (a la Steve Jobs) that can actually step into someone else's mind and figure out what they want.

That's just the thing, the developers at Apple are making software for themselves. They happen to mostly have good taste, and generally prefer to avoid using a terminal emulator for everything. This leads to great GUI software, because they use it themselves — they put a lot of effort into engineering a clever system of objects and messaging to enable their construction.

Steve Jobs does not have any particular insight into average people, he and his colleagues are just good at expressing their own taste.


We need to do the work to distill "taste" into craft, and then into engineering discipline.

That is simply not possible. Apologies.

That I guess neatly sums the whole thing up

People will use a tool that meets their requirements, but they will prefer a tool that is wonderful to use.

The first you can solve yourself by being the first to market a tool you want but no one else can give you. (this is also one of the successes of opensource - there is no market for free (beer) software product before the first open source effort. Even if a dozen companies sell it)

The second requires that you are a talented, fanatical insanely obsessive designer and have 'taste'
Chances are you aren't.

So omnigo could have taken the market for a barely-usable phone and contact book because no one else was doing it then. One mans requirements could have built a whole market.

Now, you have to have taste, style, sheer X factor. ie you need that one man to be Steve Jobs.

It was actually a Ben Stiller/Jack Black movie with the dog poo thing, not Adam Sandler.

Requirements are really just a by-product of analysis. The farther you personally are from the problem the more likely you'll mis-interprete what you're seeing.

More things are far more irrational or random than people think, or want to admit. This causes heavily biased requirements to be useless or incorrect. The trick, I think, isn't to not do them, it is to be very careful that all of the underlying facts are really just facts. And to know that even if you understand the problem, and the domain, there still might be unexpected side-effects that keep the idea from be accepted.

Paul.
http://theprogrammersparadox.blogspot.com

NAMING the product is as important as PLACING the product. Literally everyone who bikes knows about RockShox (even if they misspell or mispronounce the name as RoxShox), because it has a cool, catchy name.

But, someone who I guess bikes as often as Steve claims he did (does?), who cannot remember even a single detail of the seat adjuster's marketing attempt, however feeble, has no chance of vindicating itself in the market place.

Is there a real need for a seat adjuster? I'd say yes -- I'd buy one too. But, they had a non-memorable product.

This ties right into fashion of course -- they failed to make their product fashionable.

So, the question is whether everyone on the team has to be building the product for themselves or you'd get by with only a couple of people who want it. Or maybe even just one person. But it has to be someone you respect who is in charge of product decisions and can argue the team out of stupid compromises.

And, just maybe this is what the XP folks meant by having an on-site customer. Originally it was someone building a financial app and they got a real stock analyst to sit with them and built what he wanted because he was obviously smart and knew what to build. (And what not to build. The other big part of it is that you make the customer do triage.)

And that worked, so they made that a rule and it got watered down to "gathering business requirements" from not-so-smart customers or making the product manager pretend to be a customer, because actually finding a smart customer and making him or her part of the team is too hard for most people to bother with. (Or else they're building something nobody wants and can't find one.)

The quote you're looking for is indeed from Antoine de Saint-Exupéry. It's not specifically about writing, but about airplane design, the airplane being something that Saint-Exupéry not only used and loved, but wrote passionately about. The quote is from his memoir, Wind, Sand, and Stars:

"In anything at all, perfection has been attained not when there is no longer anything to add, but when there is no longer anything to take away, when a body has been stripped down to its nakedness."

IMHO Once you abstract yourself away from a clear motivation you're inevitably screwed as:-

a. It's the small things that count when it comes to quality - there's absolutely no way you're going to get that right if you don't have an intimate understanding of what you're after,

b. Since most software projects end up pear-shaped there's no way developers who simply don't know what will make the product work are going to know what to cut and what not to cut at the crunch stage of the project.

I'm probably repeating what you've said, but that's my perspective regardless!

That was a long post, and I read the whole thing. Why? I enjoyed it, and it resonated with me. I think you nailed it. Good job!

@Larrik Jaerico:

I believe that was part of the joke about how little research he was putting into the post.

I love a good rant, thank you!

One has to be careful when dispensing such advice, of course. In my time with software I've learned to value people over process. A great process will not allow a mediocre team to produce a great product.

So, when folks ask about process, you need to ask the tough question. Are you asking about process for great people, or mediocre people? Of course, you can't win, because everyone will tell you they have great people. Most mediocre people I encounter can't recognize their own mediocrity. An ability to do so would almost immediately make them great. Interesting, huh? (BTW, I am *very* mediocre <g>). But I digress.

Is there any advice we can imagine that would enable Mr. or Mrs. Clueless Executive Overlord to transform themselves into a Caring Eloquent Orator capable of assembling, inspiring, empowering and rewarding creative product teams? Is it just my cynical side believing that we must deliver a cruel diagnosis? "I'm sorry, the fact that you've even asked this question indicates you don't have the capacity to understand the problem. You are afflicted with terminal mediocrity. There is no cure. We're sorry."

The late animation director Chuck Jones, whenever asked about the enduring popularity of the great Warner Brothers cartoons of the 40s and 50s, would always respond, as in this interview:

Interviewer: You never really made them for children. You made them for a general audience.

Jones: We didn't make them for anybody, we made them for ourselves, which was probably the most sensible way to do it anyway.

The mountain bike seat adjuster thingy is called a Hite Rite and was produced by Wilderness Trail Bikes (a/k/a WTB) in Marin County, CA. WTB would be Steve Potts, Mark Slate & Charlie Cunningham, all pioneers in the "mountain biking" "industry". Here's a link to what appear to be dead stock Hite Rites.

Also, I think the device is from the 80s not the 90s.

The seatpost extender gizmo was called a Hite Rite.

While you say collecting requiremnets is bullshit you are actually advocating collecting requirements... from yourself. It is true that this is the best and most pain free way of collecting requirements... because you are the requirements.

It might be more helpful instead of saying you should throw out the whole requirements gathering process and instead tell people you should "become the requirements" Cultivate the ability to step into the place of the customer/user/whatever and see the world from their eyes. If you can do that, you don't need to explicitly gather requiremnets from them. The requirement gathering is an internal process.

If everyone followed your advice nobody would be willing to take big bets just a string of minor improvements on smallish stuff. Who is going to design the next power plant, jet engine or even the next printing press? If you want to limit the discussion to software, are circuit designers going to design the generation of circuit design software?

Stevey

This is a mail a consultant project manager sent us on the day the project went LIVE!

Hi XXX,

I really need to focus on finishing the requirements document. Because of this, I will be working from XXX today in a conference room where I won't be distracted. I feel that we all know what needs to be done today and tomorrow so I may not be needed.

If anything comes up, please give me a call on my cell phone.

Thanks,

--

Name Withheld, PMP
Project Manager
XXX Global Services, Microsoft Practice

I don't see how to apply this device to many non-software areas like pharmaceuticals or cars.

In the case of medical products, I may not be the beneficiary of the end result, the patient is. The doctors are usually the customers who know what kind of product they need, but the doctors may lack the technical expertise to design and implement the product itself (e.g. an ultrasound machine, or MRI scanner)

Even in the case of cars, there is a problem. Cars are not designed and built for one person, nor engineered by small teams. The cost of the process from end to end is too great, so a car is in fact, the intersection/union of many people's desired features.

Thus, your advice makes sense for small software projects, where the time horizon to implement, and cost of implementation is low, but it doesn't make as much sense to spend 5 years and lots of $$$ on something only for yourself unless a) you are only doing it for fun or b) it delivers a staggering productivity boost for yourself.

I think this is just another version of the dogmatic Paul Graham school of thought, which is that the best way to run a business is to just hack on stuff and hire hackers. Sometimes it works, but there is no evidence that it is more effective than other techniques, just more palatable to geeks who hate business types.

Your advice is fine for a consumer product, like a hand held organizer or web search, but what about products where the engineers are not the domain experts? Medical products, weapon systems, aircraft cockpit instruments, dentist billing systems, analog RF simulation software etc. etc. You can find knowledgeable people in all these areas but they are rarely the same people that build the software.

Considering the amount of companies who has no chance to build their own software - yes, it sounds weird, but there are a lot of those -, and for that reason they actually go to companies who can build softwares, your "build for yourself" part does not work all the time.

And then, if a company comes to you and says "hey, I want some software that helps me to do my work" you would say, "ok, I don't care what you need, 'cause requirements are bullshit, here is a rubber duck I bet it will be good"?

Your idea work really, really well in case you have an internal department to build software, unfortunately it is not that widespread at the moment.

I agree you on the bit where you start to gater requirements for an imaginary market and then try to sell the result somehow, but I guess when an actual client comes to you with an actual problem, you should let him explain their business and other requirements.
Like the guy who builds your kitchen furniture lets you explain what you want, and does not just pop in a general and ugly black and white hack.

I guess I'm one of the few thousand people that bought an Omnigo. I was working at HP as an intern at the time and I had a modest employee discount, but I really did want it. I fiddled with it quite a bit and used it to take notes in college classes. I used all the features, etc. I still have it somewhere.

Looking back, the only reason it failed to hook me was lack of seamless PC integration. Losing memory once a week or so (at least that was how it felt) was a real drag, and entering information on it was painful (would have been much easier on a PC). I didn't mind the size, since I usually had a backpack but perhaps that was a limiting feature for many. I don't remember 12C emulation, I'll have to turn it on and look at that!

Anyway, I think this post raises a good point, but if successful product design could be boiled down to a blog post the world would be a cooler place.

One thing that Steve doesn't highlight but that I think is crucial to understand is that with physical products, it hardly matters how good the software is. The physical interface makes or breaks most products. You can't code up a cell phone. The difference between an IPod and dozens of competitors is that they picked a simple physical interface and then did the best job they could with the software given the limitations and capabilities of that interface. MP3 players with fidgety little joysticks and multi-purpose undifferentiated buttons didn't stand a chance once the IPod came out, even if they had more features, better sound, and much, much longer battery life.

As an example, I have a bluetooth phone with Windows Media Player Mobile and a 4GB micro SD card. I had to buy a $15 dongle to turn the proprietary jack into a stereo mini-jack. After the initial exploration period wore off, I stopped using it as a music player. Why? Because there were no dedicated buttons for music, the app took many button presses to launch, and the phone was liable to dial some random number if I put it in my pocket unlocked, meaning that I had to unlock and re-lock the phone every time I wanted to interact with the player.

However, I later bought a stereo bluetooth headset with dedicated forward/back/pause/answer call and volume buttons, and now my phone is a joy to use for music (when I have the headset.) The headset doesn't work with sunglasses well, but that's another issue! It's amazing that some MP3 player makers haven't learned this 6-year-old lesson about portable device usability.

Cool, agile, minimal, etc.

But does requirements-free, spec-free really work when building a complex multi-part system with dozens of dependencies?

Your argument works for the Flip, or a streamlined minimal apps like Basecamp, or Twitter, but does it work for a Mars rover?

Recently read Beautiful Code (http://oreilly.com/catalog/9780596510046/)

Looks like to build Mars rovers you absolutely need Enterprise JavaBeans!

You, sir, have absolutely NAILED it. People get so caught up in thinking about wat to build that they lose sight of the actual problem space. Without a definition of the problem you are trying to solve, anything you build/design/thnk about will be wrong.

Thank you for this post.

"Even in the case of cars, there is a problem. Cars are not designed and built for one person, nor engineered by small teams. The cost of the process from end to end is too great, so a car is in fact, the intersection/union of many people's desired feature"

Ray, not really. The 'what I want role' for a complex endeavor can be filled by a Chief Engineer or an Architect. Chief Engineer how Toyota roll for the mass market; for marques, there is usually one person that owns what the car will be and everyone else works to that vision. Architecture is how industrial design, building and big works engineering gets done. It's how Apple do things, mostly via Ive and Jobs.

In software, we would like to have that, hence there is a discipline of architecture, but software architects don't really work like actual Architects, mostly because they don't take total ownership of the end result.

What Stevey hasn't figured out here is how it's possible for great work to get driven by people who can't actually build it. But this happens *all the time* and the excellence of the rant can't paper over this ugly fact. So when he says hire domain experts, he's nearly not wrong - it should be - hire domain experts who care enough to learn how to code. That way you get things like Rails.

Great, brilliant post. Thanks for sharing.

It seems to me that sometimes an idea simply appears before its time, before the public at large is ready for it, and suffers accordingly. (The Newton versus the PalmPilot come to mind.)

Come to that, the adjustable seatpost is not quite as dead as you think it is. It has returned, now anodized, and from a different vendor (who apparently licensed it from the original).

It's the Crank Brothers' Joplin, its history outlined by Competitive Cyclist. I just received one, but haven't had a chance to put it through its paces yet.

Lots of people have already pointed out that if everyone followed this advice literally there would be few advances in the medical field or software for running stock markets or many other products that the world obviously needs. However, in rant form this is a great bit of advice. One simply has to read through the rant to get to the underlying idea: If you need to gather business requirements, then you have already lost.

How does that work? Well, no matter what you are building, if you don't already have more business requirements than you can shake a stick at, then you are the wrong person to build it. It isn't required that you use the product. But if you are going to have a successful project, you need a pretty strong opinion about what you are building, and ideally a customer or three who are not just willing to talk to you, but positively demanding that you deliver them the product right now.

If you have to go looking for your requirements, apparently you don't know what you are building, you don't know anyone who wants what you are building, and anyone you do know doesn't want it very much.

You don't have to personally be the customer. But if you have to form focus groups in order to talk to people you hope are something like customers, you are in trouble.

"At the very least, you should hire someone who does know. Don't gather business requirements: hire domain experts."

I don't think this is an "at least." You said the bike seat failed because of fashion. Don't you think that if someone bothered to ask the guys at the magazines what they thought of their product, they could have found this out ahead of time?

This is what everyone is TRYING to do when they "gather information," and the mistake they make is asking the wrong people for advice.

Well Dehora already kind of said this, but I wanted to expand.

IMHO this idea *does* apply to cars, airplanes, medication...it doesn't matter. Why? Well, if you're working on a dashboard for a F150 Truck - are you someone that likes trucks? If you think trucks are for rednecks as you sip your latte, then LET SOMEONE ELSE work on the dashboard for the darn truck, because YOURS WILL SUCK!

Power plant? What would you want in a power plant that you would have to live next to? Should it be noisy? Big 'ol honkin' power poles everywhere? Maybe buried cables? (Sure, there's budgets involved, and you can only do so much, but you can try - which most people building power plants don't even attempt)

Medication? Easy - "Cure the illness such that the cure is better than the illness". I think we've all taken medication. We know good from bad, and we all know why. So - you're a research scientist working on a cure for an illness something you've never had? Bet you'd do a better job if you had - or if your mom had it.

Actually, I think the real issue with this method is you run the risk of making *too* good of a product. In medicine, if you create a perfect cure, the patient only needs one dose. If you only kinda solve the main symptom, people will need to take it daily for the rest of their lives. You're the CEO - which do you prefer? (Same for cars. Build a perfect car that lasts forever and is perfect-in-every-way, and it'll never get replaced).

So, I absolutely agree this method will work for *ANY* product, success doesn't guarantee profitability.

Nice post. I actually built a 92ft boat. Wouldn't call it a yacht but it is a successful business. Like you said no need for bullshit, already had customers and wanted a bigger boat.

Absolutely brilliant post, I love it. The emphasis no building things for yourself, and being excited about things that would make _you_ excited is dead on.

Blasdelf your comment is very good. I'm a fan of Linux/FOSS, and they're great for that very reason.

The most successful software I've written I wrote for myself. Others observed me using it, and wanted to use it themselves. Remove my idiosyncratic personalizations and it was complete. Everyone was after it.

You've taken the prevalence of bad analysis and design practices as evidence that they simply don't work. Doing it correctly requires a deep understanding of the problem domain, of the people who will use the product, and what technology can do. Yes, most practitioners are terrible, but it's brazen ignorance to state that analysis and design (requirements being the output thereof) are bullshit.

My experience with developers (and I include myself when I was one) has been that they are good at building things right, and not so good at building the right thing, except in the narrow space of products that programmers use. They can build what they want, and they can build what a customer says they want, but they are not effective at listening to what a customer says they need and figuring out what that actually means.

Because most clients, if you ask them directly what they want, will describe a solution based on their own flawed assumptions about technology, and they often don't understand their own problem very well.

If your sales force is saying they need a new order entry application because the one they have is slow, and you take them at their word and start building one, that's just plain stupid. Maybe it is simply difficult for them to use. (They are sales people, after all, and they use the system infrequently.) Why the fuck are the sales people entering orders anyway? Is that something customer service can do? Can the customers enter their own orders? Your going in assumption should be that whatever solutions your clients propose are at best illustrations of some of their concerns and not the actual requirement. You have to look at their business, at what they do, at the people and processes surrounding it, at the larger context in which it all happens. Otherwise you're just wasting time.

My experience has been that people who can do this well are rare and they aren't programmers at the same time they are analysts. Many were programmers, and some may go back and forth, and on small projects it doesn't matter so much, but for complex requirements it is damn near impossible to keep both models in your head at the same time and retain the necessary objectivity. If you're thinking about the code, you're going to gravitate to solutions you want to build and not the solution best suited to the problem at hand. You need to be grounded in an understanding of what is technically possible/feasible, but at the same time you need to forget about that and pretend you have magic fairy dust and anything is possible. This paradoxical thinking tend to hurt your brain and the end result has to be something doable, but it allows you to explore a solution space much larger than a "what can we build" mindset will afford. There are some developers who can do both, but you don't get many opportunities to hire them.

In the consumer space, it is the same, just fucking harder still because consumers haven't got a clue what they actually want or what technology can do and if you only target those products that developers would use and understand, then you're severely limiting your target market.

Look at a company that does this for a living well and you'll see that it can be useful. Apple gets it. How their process works exactly I don't know, but I promise that someone is doing "business requirements" in the sense of thinking deeply about what problems they are actually trying to solve for who, and how the product will actually be used in real life. When I saw the iPhone for the first time, my immediate reaction was "Apple is going to make a big pile of money" because they were the first company to really nail the requirements in the cell phone market. Everyone else previously was just building what their developers thought would be doable/cool or under the sway of designers who didn't know what they were about.

Or if you want a more generic example of someone who at least has a chance of getting it right, look at Cooper design. They have some concept designs posted on their website that are, in my opinion, examples of what a "business requirement" should look like. Note that while the designs could be built, there's nothing in the requirements about how they should be built and there are some interesting business and technological challenges that would need to be overcome. I would suggest that many or most successful technology products (iPhone, again, for example) are the result of solving such interesting challenges and therefore one benefit of good requirements is that they can direct our attention to the problems worthy of solving if we want a successful product. Too often we invest time in optimizing or creating features that nobody actually cares about.

Anyway, aside from being completely wrongheaded and misinformed, nice post.

I sort of see what you're saying, but how does it fit with the way we work;

I work within a large software company, working on a single piece of enterprise software that is used by hundreds of clients, all paying for developments to the software. These modifications are agreed months in advance of scheduling for development, through a process where requirements are discussed with the client, estimates given, specs drawn up and negotiated over etc. If the clients aren't going to give us their requirements of how they need the software to work slightly differently in some area of functionality, where are we supposed to get them from - guess? / run their business for them so we have the same issues?... The way our business works just doesn't fit with what you are saying.

Enjoyed the rant tho, ta

@Michael Head - You can find fully rigid bikes, but it's a niche market. Same as single speed or fixed gear bikes. The reason suspension caught on is because it had a direct and undeniable benefit to riding more extreme terrain faster. The seat extender is really just about convenience.

@entaroadun said...
"Usability in open source projects is a real problem, since nobody incapable of building software themselves will be able to use it."

Are you serious?

By the way Jobs is very skilled at persuasion and salesmanship, but he has not so much to do with the design of the latest apple products.

This comment has been removed by the author.

that's just awesome.


I'd love to translate it to Russian if it wouldn't so lengthy. ;)

I don't understand. My previous job, I worked on a transaction processing system for our company. Our demands were unique, so bespoke software was the only viable option (previously we'd tried using off-the-shelf systems but they were a poor fit, hence the internal development).

None of the developers were accountants. We knew how the business worked in broad terms, but there were specific details which we didn't know, and had to learn from the accountants. They were business requirements, and I cannot understand how they are "bullshit".

I think also it would be pretty retarded to demand that everyone at a pharma company has cancer or AIDS or whatever else before they look for a cure. If other problem domains can establish business requirements successfully, it suggests that the problem is not business requirements at all.

As mentioned in the very first comment, make-what-you-want has been how good Open Source projects start since AFAIK forever. This blog kept sounding to me like a pithy distillation of The Cathedral And The Bazaar.

Great post, very succintly put.

I think Steve's premise makes sense in the context of creating products, but not all projects are about creating products, as drpizza's comment demonstrates.

If you are building a custom solution for a company that has a specific need, it is far easier (and obviously far more necessary) to gather business requirements, or whatever you want to call them. I generally prefer to call them business rules, because it helps the customer to visualize that what they tell me is going to be enforced or carried out in the system--in as precise a manner as they are capable of explaining to me.

But a product is more of a general thing, and much harder to nail down if you don't "own" the concept. I have worked on projects to create products, and projects for specific business solutions, and I agree completely that building a successful product HAS to be a labor of love, and no amount of focus groups and marketing consultants is going to change that. I suppose the one exception to that rule would be those who get a real kick out of duping the gullible with pointless products that do nothing but extract money and dignity from the customer. But that's another story.

Voltaire said that a book is finished not when nothing more can be added but when nothing more can be taken away.

Well...I at first had to double check where I was reading this from...this is a guy I know who only says smart things right?

Well after reading in between the lines I 'got' what you were saying, but I can definitely see where those of us involved in the IT shops out there could read this wrong if they don't know Stevey from previous posts or read this post in its entirety.

Don't forget - we're not writing software for us and we have to hold people's hands and bring them to a room and write everything down for them to sign off on (otherwise they'll never say that's how they wanted the system to work and it's a bug). IT is a whole different animal from writing the type of software mentioned here; in my opinion at least - and in IT you need business requirements to CYA and keep projects from going on indefinitely.

Steve, it seems that after praising rails you continue to borrow from the 37signals book:
Build less and
Solve your own problem

By the time every knucklehead in the production chain has Chinese whispered their agenda into an original idea that shoulda worked the end result is a coding camel that will never work. Like ... [insert example that just came to mind here]. You know the one.

Solution - remove all the knuckleheads and/or remove their effect.

Everyone keeps pointing to the medical field as somewhere where this wouldn't work, but that's not true at all. If you look at the history of medicine, the different imaging modalities were all created by people playing with awesome/fun tech (plain x-ray, CT, ultrasound, MRI, SPECT, and PET) and they managed to figure out a way to actually use it to help patients AND make their work easier. In fact, pretty much all the major advances in medicine worked this way (vaccinations, penicillin, coronary artery bypass graft, coronary artery stents, etc.) The general thought process is "how can I best help the patients who I'm taking care of." And to have the highest likelihood of succeeding you probably have to implement the process or prototype the machine yourself, because no one else will care.

Surely what Steve says sounds like crazy talk to many but it rings true for me. Could it be that a major contributor to this "requirements" problem is a wrongheaded approach to education? I happen to think "modern" education from preschool right up through university is broken because we concentrate on preparing people for jobs they "do" instead of firing peoples' passions.

Requirements are just the future features. You have to imagine them.
So you can't gather them, you have to design them. The future features are always desirable once they are seen. Show the customer the features and they will immediately claim: "Yes, I want that. That's a requirement. So it must have that little slider for the energy level, and a dial for the timer, just like an egg timer...."
Otherwise you are going to build a yet another microwave oven with an digital watch logic interface that can reheat fried camel's liver with one touch.

*Someone* has to build software for people who have a need and can't build it themselves -- see Alan Cooper's The Inmates are Running the Asylum for some good ideas on how to do it (and it takes more than just focus groups).

I see where you are coming from. But unfortunately, not everyone can write software that they are going to use. I write software for radiology and the last I studied biology was 12 years back, let alone any radiology. Yet we have to get into the brains of the radiologists and understand business requirements. What do you have to say about this?
Swati
(http://differentworld.blogdns.org)

This reminds me of something I derived from an article by John Gruber, and it's something I am sure others have "figured" out as well. But the way I see it whoever is in charge get what they ask for / demand. If you ask for status reports, you get status reports, if you ask for business requirements, you get business requirement, and if you demand a kick ass product, you might just end up with exactly that.

This thinking ties in really well with Mr. Yegge's ranty rant. To know what to demand, you need to know what you want, and to know what you want, you must want it.

I also feel that a lot of the comments here seem to think that whoever want the product, and demands it, also has to be the one making the product. I don't think that is necessary. Good old Jobs is a good example of that. He wants to stand on the stage and hold up the latest Apple product and say "we rock, we ownorz you the Dells and Microsofts" and that is what he demands. He doesn't need to know how to manufacture or design an iPod, nor how to best make use of a NSTableView for high performance. He just needs to know what he wants, just like John Cleese as the pope :)

Not to attack anyone personally, but that's the reason why most medical software sucks: unless they are/were practicing physicians themselves, the people doing the programming have no way of getting into the minds of the people who use it, and then we have to endure craptastic EMRs and CPOE systems, until someone complains enough, and then we get something slightly less craptastic, until *that* collapses under the weight of actually usage. Is there a solution? Certainly nothing cheap or easy. But there are plenty of people in the medical field who also know how to code, and it's no surprise that the better packages out there (by no means even close to perfect) come from these folks.

ROFLMAO! This stuff is hysterical!

1. "I find that a lot of Free Software is terrific for exactly this reason — the authors built it for themselves." I find that a lot of free software is unusable for exactly this reason - the authors built it for themselves, and don't give a rat's patoot about documenting for others how they imagine in their genius minds how their product should function.

2. These comments sound like they came from the same mind as that Rails developer who opined that he couldn't imagine an application having more than 20 tables so what's the big deal if Rails can't support large schemas. This faux-libertarian naive hacker mindset, in which everyone can and should "do it themselves" in a world where we all are responsible for doing our own brain surgery ("Why farm this out? After all, it's YOUR brain, isn't it? Take responsibility!"), is just getting old. Some things just are complicated, and no one person gets the whole picture, especially in a real business enterprise environment and not a "look, I made another to-do list app for the iPhone" world.

Does this mean we abandon all complex projects in which (horror of horrors) research and analysis actualy need to be done to figure out and accommodate the needs of multiple interested groups of people, not just other hackers who think your to-do app is neat? I would imagine not, but I could be wrong.

The requirements derivation process is still very broken. But saying "we don't need to have requirements at all" is not an answer, it is an abdication.

undisonus, that cuts both ways. There is also no end of crap software written by "subject matter experts" in this or that vertical industry, and this goes twice for the medical field, I think. ThedailyWTF.com is full of such stories. Think of the kind of software produced when a few doctors get together and decide that they have the expertise, so all they need to do is hire a "computer guy" to make it happen. The problem is, they may have the domain knowledge, but they don't have the judgment to know who is the right sort of programmer to hire. So you will find the vertical software industry rife with misplaced people: someone who did a few Microsoft Access databases suddenly finds himself tasked with creating a full client-server-database system to coordinate records between multiple medical offices, for example, or maybe even an accomplished old-school C coder finds himself struggling to write a web/AJAX application.

This goes back to the programmer, of course. Programmers love a challenge, and it is very tempting to throw oneself into a new field with a fresh set of problems to solve. And of course, you can grow tremendously as a programmer by doing such, and some fields can benefit greatly from a fresh perspective. But that only works when the programmers and the experts have enough savvy to identify competence in each other, and to know that fine line between recklessness and courage.

Chad and Swati make the important point here - imagining that everyone can and should be creating their own software for their own needs is not just native and pollyanna-ish, it's downright dangerous. The genius hackers who don't care whether their software is understandable by others, who shout "then write it yourself!" at people who criticize them, doubtless they get their cars fixed at repair shops, their long distance plane flights conducted by professional pilots and airlines, and their ailments dealt with at doctors' offices. (Unless they choose to be their own brain surgeons...) Perhaps for a small number of such people their sexual needs actually involve interacting with other people, too. :-)

I make light of this behavior and attitude, but the point is that DIY has its limits. We live in a world with other people, and unless your a libertarian militia mountain man type in a cabin in the woords, your life depends on interaction with other people. You cannot and should not (despite what these mountain men may bellow out while beating their chests) be expected to do it all for yourself. That's why we have specialists in the world, and work together with them to facilitate improvements to our lives. As long as this is true, there needs to be interaction between people and communication to convey ideas and requirements for real-world projects. Much as this may upset the anti-social types in our profession, it is the way it is. The process of conveying those requirements, as I said, is far from perfect, but it's all we have for the moment, and in a world where we ARE dependent on each other, improving that process is key to success.

In an excellent book from 1990,
Wicked Problems, Righteous Solutions, the authors say that getting to a righteous software solution requires someone whose head is completely wrapped around the problem and the code. This guy has to know what needs doing, and also how the code is architected and implemented.

Your diatribe against unfocused requirements-gathering seems to reiterate this point.

So, after telling us all what you told this C*O, one question still lingers: did this person respond with an awestruck gasp of epiphanous wonder saying "yes, I get it now, I should stop seeking to have business requirements defined for the projects my company is working on!"

Or... did they ignore you and look for someone with actual real-world experience and wisdom on the imperfect subject of building complex real systems for complex real people?

You didn't say, so I have to assume the latter. :-( The question is, why doesn't this matter to you? Or does it?

Gosh, Dodge, what an ironclad and compelling argument! Thank you for sharing a thimbleful of your boundless wisdom with us, the unwashed masses.

It's true, no one has time to do all these things on their own, but the important thing to realize is that letting someone else do it is a compromise. That compromise involves dealing with crap that you don't actually want. That's life.

So we slog through non-ideal situations where we know there could be something better. Thus, we have things like Windows, and the ancient x86 architecture.

But this disconnect between implementor and user is a significant contributor to the reason why the field of medicine has been slow to adopt new information technologies, and why it hasn't really benefitted significantly from "computerization." There are some young physicians and nurses who sigh with relief when the system actually goes down and we can get work done with simple paper orders and phone calls. It makes documentation hell, but we don't have to fight with the stupid computer.

But if you actually want to make something that'll stand the test of time and actually fulfill the needs of audience/target user/target demographic, you have to do it yourself. Perhaps the best EMR/CPOE system out there is the one deployed by the VA: VistA/CPRS. This was entirely an in-house development and was motivated precisely by the desire to cut the administrative crap and just get something up and running that would actually be helpful, and not a pain-in-the-ass hindrance. Sure, it's got its headaches and its annoying behaviors, and it's absolutely broken in a lot of ways, but I don't think anything out there even approaches it in applicability to clinical practice.

I hate to say this, but I think that what you have done is to distinguish a good requirements gathering process from a bad one. You certainly have to have engineers that understand the domain well enough that they know how to lead implementation of the requirements, but they won't have time to be out and about meeting 1001 customers to get a feel for what should be in the next release, and talking to other business groups you need to integrate with. And, you need to be able to plan with accuracy a launch, and very likely that launch will be coordinated with other complementary product releases so a lot of planning is needed.

So, I agree that requirements gatering can be done badly, and often is. I would say the worst possible scenario is where the engineers don't accept the necessity for and the validity of the requirements, but just go their own sweet way.

FYI, your Subway investment analogy is a poor one. There's a classic business case about investors in the Au Bon Pain bakery chain; since people liked their croissants, they thought they were experts...as it turns out, eating there several times a week didn't give them insight into the company's management problems. A lot of folks lost a lot of money as a result.

See section 4 of this CNN/Money story as reference.

You might even consider this business case to be a general counter-argument to your thesis.

Yes, for every rule there is an exception and the only rule without an exception is 'for every rule there is an exception'. So it in itself is its own exception, which therefore proves its own premise that 'for every rule there is an exception'.

[dizzy]

Your critique of the 'Subway investment analogy' is poor. You are pointing out an exception.

Perhaps the buck doesn't stop at just using the product yourself. Maybe you still need to do your homework on the market but I am still going to stick with Warren Buffets advice over yours 'Latex'.

Back in the 80s a classmate shared a little known beverage called 'Snapple' with me. I thought it was great. And when I was given a chance to invest some savings money I had, along with my older brother, I put about $400 in Snapple. He put his $1200 in IBM. In 2 years we both had $800. ;)

(PS. I am sure you can find an exception ... but IMO don't bother)

I'll second the recommendation for The Inmates are Running the Asylum.

Some of your ideas sound familiar, have you read Maeda's Simplicity?

I really liked your statement about taking somebody else's idea and removing something.

The perfect combination seems like above "Build What You Know/Like/Need" + "You Ain't Gonna Need It" = Nirvana.

I've worked in the past for a few crusty old-timers whose attitudes I regarded as quite Philistine at the time, but whose wisdom I've come to appreciate.

My two product examples couldn't be more different: one was a roofing product and the other was a piece of software.

At Owens-Corning Fibreglas, Al Marzocchi (the inventor of the fiberglass-reinforced tire) had me work on a flexible roofing product. I wanted to do all kinds of lab testing. He wanted to find someone willing to pay for it (with a money-back guarantee), put it on a roof, and see if it worked. In fact, it failed, but we sure found that out a lot faster than we would have by doing a lot of lab testing or by going out and asking for requirements.

Then I did a computational post-doc for Cy Levinthal at Columbia. I was proud of something I had done and commented that I thought it was an "elegant solution." He sniffed and said, "Elegance is for tailors."

Now I write and manage the writing of commercial software. The lesson I've learned is Get the idea; Implement it simply and don't gild the lily; Sell it (don't give it away!) to lead adopters; Respond to their complaints. (Actually, for the last such product I did, I have to be honest and say that I did speak to the prospective lead adopters first and tried to respond to their concerns. But this was to tweak the initial feature list, not to get the basic idea.)

If you ask customers, "Would you like X", they will nearly always say Yes. Why wouldn't they? Having the choice to buy it or not is free to them. You'd be surprised at how honest some of them are when you ask, instead, "Would you pay $Y for X?". But the response is still exaggeratedly positive. If you give the first version away to those who said, "Sure, I'd like it", very few of them will even try it. But if they have to pay, then, on the Maharishi principle, they'll sure try it, and they'll sure tell you what they don't like.

If, before deciding what to produce, you ask customers what they want, they will often come up with something that is either overly specific or underly imaginative; but if you then respond with "OK, but what if I give you this other thing instead?", they will sometimes say, "Wow -- can that really be done?"

For all of us, our thinking is straitjacketed by our experience. Developers and inventors can sometimes see beyond the horizon that limits typical user thinking. By the same token, what's cool to us sometimes turns out to be incomprehensible or useless to them.

Thus, keep the first version simple; sell it; and, based on response, either abandon it or use customer response to guide the next version.

are you summing up the world as a short race for money?

if not, and we all do not HAVE to be Warren Buffet,and life itself being a random-logic play, each player must say his/her line and NOT repeat co-stars lines/actions, because then it would be so downright dull here on earth, ideally then we must invest/act in a way that is uniquely written/wired for us.

but then, i guess ten commandments did work for our species(?), so rules is what man must have craved for..
if you want to get wealthy, do what *Warren does..
if you want to write code, do what *Stevey does..

will we never say our own lines?and stop stepping on our co-stars foot?
to make the certainly random, perfectly disciplined..ah!

i am sorry i am in software discipline, but i guess i fell in love with chaos :-)

Well I'm just going to have to be an ***hole here and point out that gathering business requirements isn't bullshit. In fact it is one of the most important stages in the life of a software project. Just because gathering requirements is difficult doesn't mean its stupid. If you live in the real world, then I'd check out the (rather condensed treatment) in CC/2e and then skim something by Wiegers.

You have made some valid points and provided some nice entertaining reading, but what about companies that have users that want developers to automate a bad process to begin with? Without an objective 3rd party to look at the big picture and determine the impact (to the organization) of what the user "wants", many companies tend to wind up with a hold lot of automated crap.

“It's just that when the project implementation team and the target customer aren't exactly the same group of people, then there are inevitably negotiations and compromises that water an idea down about two levels of quality: great becomes mediocre, and ideas that start as ‘pretty good’ come out ‘just plain bad.’"

Thanks, Steve. I enjoyed the rant. To an extent, I agree with part of it, the product of gathered requirements CAN be bull**** if you do it wrong. In a software development environment, an effective Business Analyst must understand the business, customers, development team, systems, processes, constraints, and capabilities. Then, document in language simple enough for a 6th-grader to understand, bringing them all together for a common purpose: push everything past its limit to make them all better. What could possibly go wrong there? Be the best you can closer to perfect than bull**** as often as possible.

"..you're done writing not when there's nothing left to add, but when there's nothing left to take away.."

Please keep that in mind when writing blog posts. Love ya! :)

You're painting in rather broad strokes to say that gathering business requirements is bullshit. In the world so many of us inhabit, where our customers come to IT and ask for a software solution to help them run the business we're all a part of, gathering business requirements is the best way to get something bigger than a small add-on done.

This is not to say you just take whatever the customer says are the requirements as gospel and move on from there. The person gathering the requirements has to understand what the problem is, however that is accomplished, in order then to understand anything about potential solutions.

Business requirements are the bridge between the customer who needs something and the person who can actually create what they need.

I agree there are some valid points in your very amusing blog (and some very amusing posts as well). But I disagree with the overall theme of Business Requirements are bs'; especially in an in-house software development group. I think detailed information about what the customer needs is critical to the success of a project. And I think that there are three major players that are needed for accurate, complete requirements: A customer who knows what they need, a BA who can help the customer realize what the customer needs (if they don't already know) and who can translate those needs into understandable requirements, and a developer who actually cares about what the customer needs and wants to help the custmer and wants to provide the best possible solution FOR the customer's needs. (This is one of the parts that I agree with). I think if developers had the best interest of the customers in mind, and took at least a little time to understand the customer's world and subsequent needs, then they could ultimately offer better options and build better products the the customers could be excited about.

Some of us are building things that are almost by definition not for personal use. That is, there's no way I could actually have a chance to really use the software I'm writing (other than by way of playing out fictive test scenario's, of course), because that function belongs with a specific kind of profession, and I cannot be both a S/W developer and this other profession at the same time. But that being said, clearly it is important to "love" the thing you're working on. If you don't even like it yourself, how can you expect others to...? (OK there are many systems that don't have to be "liked", they must just work - i.e. embedded stuff without any direct user interaction...

Steve,
I enjoyed the walk down memory lane. I still have my OmniGo. Did you know that the Flip was made by Jonathan Kaplan, of Geoworks fame?

Have you had a recent look at Airset, which Brian is building for himself?

I agree with droher. And clean up these spammy posts! I love yer blog.

maybe he just introducing and advertising his product that's why he just emailed whomsoever...
_______
miles

maybe he just introducing and advertising his product that's why he he need to email whomsoever even he doesn't know it..
_____
miles
http://mls.fastrealestate.net