|
 Steve
Yegge: Your requirements are stupid
By Jesse Noller
Lately, I've been ruminating on requirements and
requirements management (also known as disaster control). I was actually
typing something up on this, but Steve Yegge
hit the nail on the head - then he rammed it through the board and into
the house next door:
Anyway, there you have it: the slightly
expanded version of the email I sent that CEO guy. Gathering business
requirements is hokum. Hooey. Call it what you want, but it's a sign of
organizational (or individual) cluelessness. If you don't already know
exactly what to build, then you're in the wrong business. At the very
least, you should hire someone who does know. Don't gather business
requirements: hire domain experts.
Also, FWIW, here's the hackernews
discussion. Here is a
link from one of the comments pointing to something Linus once said
about specs:
they're dangerously wrong. Reality is
different, and anybody who thinks specs matter over reality should get out
of kernel programming NOW. When reality and specs clash, the spec has zero
meaning. Zilch. Nada. None.
I think one of the comments also added something
spectacular - noting that "building something for yourself" is why so many
open source projects flourish. If you're building something useful for
yourself - there's a high chance that someone else is going to want to
A>Use it B>Buy it - "building for yourself" is also in some ways,
"keeping the vision clear".
One of the key concepts which seems to be the
undercurrent to what he talk about is vision. You need someone who can
stand up and say "this is what the product is, does and where it is going".
You need that visionary who can clearly outline what itch you are trying to
scratch. In open source - that's the project "core" - in business, it's the
CTO or founder. It's always the person that had the itch, they've "walked a
mile in the shoes" so to speak.
That vision has to be the core of both the product, and
all of the requirements - this "clarity of vision" (some might say
"simplicity of vision") is what makes so many projects and products
successful.
Sure - as you grow you'll add features: You don't want to
stagnate - but those features have to make sense - they have to mesh with
the core vision of the product. You don't add a source code management
service to say, twitter.
Why? Because even if 1 customer thinks "that it would be
AWESOME" - you're going to spend $X hours of engineering time gluing a
volvo on the side of your battleship, and unless those $X hours are
compensated by the amount of money the customer is willing to pay (it never
is) you've wasted time, and muddied the functionality and philosophy of the
product. It's about as useful as a screen-door on a submarine.
When you're thinking about requirements ask yourself
this: If at the start, you can not describe exactly what your product does
in under a minute - you've already got a problem. If adding this feature
makes it even harder to describe/encapsulate the vision and capabilities of
the product you're rapidly running towards wronger-than-wrong.
If you yourself would not use the feature: Does it really
make sense? When a customer requests a feature - does it make sense for
anyone outside of them? Would you be better served by providing an API and
an SDK?
This is the beauty of things like a clean API - you can
keep the philosophy and core of the product/project clean and empower your
users to build any number of things they want on top of your product. Keep
it simple, keep it clean. Empower your users to "mashup" as they need or
want to.
Think of it terms of cooking: If you wouldn't eat it
yourself, in all likelihood your customers won't like it, at best it will
be mediocre. The best chefs taste and consume what they cook.
Right now I'm wishing Brian Fitzpatrick's keynote from
pycon: "You *can* Fool All of the People All of the Time" was online in
video form.
Until next time,
Jesse Noller
To read
more of Jesse's work, visit his blog.
|
Back to newsletter list
Perspective
