
Business Requirements are Bullshit - mqt
http://steve-yegge.blogspot.com/2008/08/business-requirements-are-bullshit.html
======
edw519
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.

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

~~~
edw519
_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.

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

~~~
edw519
There are over 800,000 programmers working in the U.S. alone, an overwhelming
majority employed by someone else.

<http://answers.google.com/answers/threadview/id/43888.html>

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.

Welcome to the real world.

~~~
Retric
Most: ERP, accounting, banking, claims processing, ecommerce, order entry
software _sucks_.

Scientific software is often started by someone who uses it and tends to work
well.

~~~
edw519
_Most: ERP, accounting, banking, claims processing, ecommerce, order entry
software sucks._

You're probably right about that.

But _enough_ of it works to run the world. No small feat.

~~~
sapphirecat
There's a yawning chasm between "works" and "doesn't suck".

------
bdfh42
I think that Mr. Yegge missed the real question - but the rant was worth it. I
particularly liked "The easiest way to build a product that kicks ass is to
start with someone else's great idea (camcorders, for instance), and take
stuff away."

I suspect what the "business correspondent" wanted to know was something more
like:

"My customer wants me to build him a new billing system. Their top managers
have some defined strategic objectives but no-one I have met seems to actually
know what this system should do in any detail. However, they can all detail
the bad things that would happen if it did not do (whatever it is) perfectly
from day one. Now how do I find out what to build them?"

Now that question is the one that development teams face every day.

~~~
mattmcknight
And would the answer then be, join the billing the team for while, learn their
processes, and then build a system to make your job better and provide value
to the project sponsor.

------
akeefer
I'd like to point out that this article completely ignores most specialty or
enterprise markets. As a maker of insurance software, we employ some people
who were former insurance agents/adjusters, but none of our developers are,
and our only real hope for understanding exactly what has to go into something
like a policy administration system is to get out there and talk to customers
and potential customers. Even within an insurance company, the developers
still won't have a clue because it's not a product they themselves would ever
use, and they'll have to rely on someone else communicating the requirements
to them.

The same is probably true of just about any other business-focused software;
most developers aren't hedge-fund traders, auto mechanics, laywers, hotel
managers, etc. yet somehow people manage to build specialized software for
those fields. You need people in the organization that understand those fields
and what's involved, but the motto of "make something you yourself want" just
doesn't apply when you're writing software to run an entirely different kind
of business. Developers can be mountain bikers on the weekends, but they're
generally not insurance agents or doctors in their spare time.

~~~
gcv
True enough. I deal with "enterprise" software all the time, and I found that
it is all horrific. Terrible UIs, almost invariably terrible performance,
chronic instability. I'm afraid that, if Steve is right and that to build
something good it must be built for the builder, there will never be good
"enterprise" software.

Also: requirement gathering in that market is just as frustrating as Steve
says it is in the consumer market. I've dealt with lots of people who ask for
features and then change their minds or realize they didn't really know what
they wanted.

------
michael_dorfman
He raises many good points in the course of the rant, but I think that "only
build for yourself" goes a bit too far than most of us are willing to go. I'd
suggest, in the spirit of compromise, that "gathering (and understanding)
business problems" is a better practice than gathering requirements, as user-
proposed solutions (and the requirements which make them up) are often doomed
to failure.

~~~
axod
Why is only building for yourself a bit too far? This seems like common sense
to me. If you're not using your own product day in day out, you should be.

~~~
michael_dorfman
Because I may not be in the same line of business as my users. For example, my
last start-up develops planning software for large agricultural firms. I don't
happen to manage a large agricultural firm, nor am I likely to manage one in
the near future.

Still think I should be using my own product day in day out?

~~~
stcredzero
Nope, but if you can, hang out with the actual users jockeying the software as
often as you can. I know that I learn something new almost every time I go out
on the trading floor and have a user walk me through the software I'm writing
and fixing.

~~~
michael_dorfman
Absolutely! And that was my point-- you need to understand the user's problem-
space very well, and there are better ways to do this than the traditional
"business requirements gathering" process, which tends to focus on the (sub-
optimal) solution the users have already imagined.

~~~
stcredzero
It shouldn't be "business requirements gathering." It should be "business
requirements refinement."

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

~~~
sapphirecat
> But the right way to do it is to have smart actual users talking directly to
> smart actual devs.

I find in my own software that the best thing to do, if you're improving an
existing process, is to watch (or participate in) the current process, with an
eye toward the parts which waste time or irritate people.

In any case, after the initial study, it's crucial to back out of the details
of the process and think about the overall goal to be accomplished. You don't
want to waste effort evolving a process that's been badly distorted by
existing software, when you could simplify the process immensely by writing
something directly focused on the actual goal. This is an intensely
creative/intuitive phase of the process, so it often takes several iterations
(from a fresh state-of-mind each time).

Once you think have the perfect solution, go back and make sure that it solves
all the problems noted in step 1. If it doesn't, try again.

~~~
joshwa
Of course, that assumes you are actually permitted to change the process. The
project I'm working on has the constraint that while we are allowed to write
less-buggy software that catpures the existing process more effectively, we
are not allowed to propose changes to the existing process (which evolved
around the existing cruddy software-- 10 years of accumulated process and
"feature" cruft, now cast in carbonite).

Corporations sometimes have a funny definition of "risk." Sometimes,
Risk(changing to a sane process) < Risk(reproducing unnecessary complexity of
existing process).

~~~
stcredzero
True story: A friend of mine wrote software for NASA. There was an old control
system for something that had as its interface a 9 key keypad a numeric
readout and something like an enter key. The system was modernized, and its
software was ported to Unix workstations. However, to keep it compatible with
the operations manuals, the new GUI interface just simulated the keypad and
numeric readout.

(This is not software that my friend wrote. He ported the "numerical
integrator" program used to track the Space Shuttle in orbit and calculate
abort trajectories during launch. And yes, he showed me the program with the
keypad! Another thing: as I was walking around at JSC, I saw a "Unix for
Dummies" book back there!)

------
biohacker42
Good rant, but I want to talk about dog poop.

Surely there must be an enzyme cocktail that can evaporate poop! You would not
use it indoors, only for outdoor use. But there must be something that will
decompose dog poo super fast. Any organic chemists here?

~~~
kirubakaran
Genetically engineered dogs that excrete sealed tubes will put you out of
business.

~~~
Leon
Robot dogs will put you out of business.

~~~
whatusername
Virtual Reality (plus an exercise pill) will put you out of business.

It doesn't mean that there isn't money to be made each step of the way.

------
tidra14
I think what the article was saying is: Use common sense

And: People do not know what they want, or to be more precise, decisions of
liking or not liking something are made seconds before the person becomes
concious of their choice, so most of the people's desires are subconscious and
what they say they like is simply a justification and not their true wants.
(which has been proven through psychology research)

Of course both the advices are sound, but man what awful and utterly terrible
writing.

The guy is patronising, his speech is in your face and he has no consideration
whatsoever for my time. He babbles and rambles about useless stuff when I
simply want to get to the point of what he is saying and move on.

So to give him a bit of his own medicine, was he actually writing for himself?
Or was he writing for others?

The answer is rhetorical of course, he knows his stuff so there's no need to
write what he knows unless it is aimed at others. So he is not writing about
himself he is writing about others.

Now that he wrote for others was his writing mediocre?

Perhaps, I certainly think so, but was it how should I put it, popular? Well
64 comments from fellow hackers, loads more in his own blogg, probably loads
of nutters linked to it.

So would he care to define mediocre?

I just do not know how anyone can read his blog to be honest.

Hello by the way, my very first comment, I'm Andrew, Nice to meet you all :)

------
bbgm
Steve has obviously never had to develop software for the life science
industry. My response to any such post is simple. It depends. It depends on
the kind of application, for what kind of market, etc.

I've seen more than my share of applications done in the "this is how I would
use it" fashion and the results have been disastrous. I am sure there are
examples, perhaps a first take or prototype that reflects what your ideal it
and then you whet it with people out in the market, but you have to ask
yourself "what problem am I trying to solve?". You have to ask yourself (cause
if you don't someone else will) the "so what" question.

It's not about the process, which is where a lot of requirements gather bogs
down (IMO, every time you talk with a current or potential user, or even a
hater you are collecting requirements). It's about really caring about the
problems you are trying to solve and why someone would care about the way you
want to solve it.

------
signa11
this (<http://kerneltrap.org/node/5725>) is soo much better.

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

~~~
stcredzero
Linus has an easier task. The hardware the kernel runs on and the software
running on it act as an ironclad, rigorously defined spec. Dealing with human
users is something else.

~~~
signa11
not really true. what would you say about git ? it has no kernel components,
no spec (at least not that i am aware of).

~~~
stcredzero
Linus wrote git for himself.

------
randome
His post is bullshit, opensource software sucks for this reason ... its built
by a bunch of hackers that don't know anything about interaction design or
what customers want and need, don't know much about much of anything other
than the technical.

Its great when the users are all techies ... but in my opinion most of the
desktop apps suck ... openoffice is a piece of shit.

I totally agree with edw519 ... this guy just doesn't know what a product
developer does or how to do it. Contrary to the elitist hacker opinion that
these people don't know what they are doing ... effective, methodological
product developer actually do contribute significantly to finding out what
people want. A lot of programmers need to let go of their egos and realize
that they are not know-it-alls.

------
maxklein
Over complicated business requirements are bullshit. But starting a product
without researching first is a recipe for disaster, particularly if you are
entering a crowded market.

~~~
edw519
_Over complicated business requirements are bullshit._

What if the requirements _are_ complicated?

Go ahead and develop an arbitrage system, a medical claims processing system,
or a repetitive shop floor control system without "complicated enough"
requirements and see how far you get.

~~~
maxklein
Over-complicated is the same thing as too complicated, which does not put a
limit on how complicated a system can be.

~~~
mattmcknight
Over-complicated is also a tough guideline to follow, because how do you when
you have "too much" complexity?

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

------
pongle
Hmm, I'm not convinced about the "only build what you are going to use"
argument. The best example I can think of is pace-makers (or any other form of
life-saving equipment). A manufacturer of these devices cannot be a user,
because they'd be dead...

~~~
stcredzero
I'll bet that a pacemaker embedded software developer who personally knew
patients with a pacemaker and hung out with them every day would be a whole
lot more motivated.

~~~
astine
Just to add to that: I imagine that the makers of the first pacemakers were
doctors who were better in tune with the need than the patients. In fact, I'm
pretty sure that doctor, not the patient, really counts as the target market.
He's the one the diagnoses the problem (and understands the need); he's the
one that actually orders the devices; he's the one that actually orders the
devices. The patient generally only needs to know that he needs one, and that
it's going to be installed.

In the same vein, I'll bet that if actual accountants were to design a piece
of accounting software, it would probably rock pretty hard. (Assuming of
course, that the accountants in question were also competent
designers/developers.)

------
misterbwong
After reading the discussion, is anybody else wondering _why does this have to
be so hard?_

There has _got_ to be a better way to find out what the user really wants.
Tools like balsamiq are a start, but it seems like this is a HUGE area that
needs improvement.

------
Jaytee
I'm gonna quote Bruce Lee and apply it to everything here.

"Take what's essential, discard the unnecessary, and make it your own."

That's the point I got from Steve's post.

And that's how I dealt with his rambling.

Meta-great post.

------
prakash
can someone provide a cliff's note version of what Yegge wrote? I tried
reading what he wrote, but there is too much rambling.

~~~
axod
Don't try to find out what potential customers might want, just build
something where you are a potential customer - Build for yourself.

That's what I took from it anyway :/

