Steve Yegge hits a homer: Your requirements are stupid.

August 12th, 2008 § 11 comments

Lately, I’ve been rumi­nat­ing on require­ments and require­ments man­age­ment (also known as dis­as­ter con­trol). I was actu­ally typ­ing some­thing 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:

Any­way, there you have it: the slightly expanded ver­sion of the email I sent that CEO guy. Gath­er­ing busi­ness require­ments is hokum. Hooey. Horse­shit. Call it what you want, but it’s a sign of orga­ni­za­tional (or indi­vid­ual) clue­less­ness. If you don’t already know exactly what to build, then you’re in the wrong busi­ness. At the very least, you should hire some­one who does know. Don’t gather busi­ness require­ments: hire domain experts.

Also, FWIW, here’s the hack­ernews dis­cus­sion. Here is a link from one of the com­ments point­ing to some­thing Linus once said about specs:

they’re dan­ger­ously wrong. Real­ity is dif­fer­ent, and any­body who thinks specs mat­ter over real­ity should get out of ker­nel pro­gram­ming NOW. When real­ity and specs clash, the spec has zero mean­ing. Zilch. Nada. None.

I think one of the com­ments also added some­thing spec­tac­u­lar — not­ing that “build­ing some­thing for your­self” is why so many open source projects flour­ish. If you’re build­ing some­thing use­ful for your­self — there’s a high chance that some­one else is going to want to A>Use it B>Buy it — “build­ing for your­self” is also in some ways, “keep­ing the vision clear”

One of the key con­cepts which seems to be the under­cur­rent to what he talk about is vision. You need some­one who can stand up and say “this is what the prod­uct is, does and where it is going”. You need that vision­ary who can clearly out­line what itch you are try­ing to scratch. In open source — that’s the project “core” — in busi­ness, it’s the CTO or founder. It’s always the per­son 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 prod­uct, and all of the require­ments — this “clar­ity of vision” (some might say “sim­plic­ity of vision”) is what makes so many projects and prod­ucts successful.

Sure — as you grow you’ll add fea­tures: You don’t want to stag­nate — but those fea­tures have to make sense — they have to mesh with the core vision of the prod­uct. You don’t add a source code man­age­ment ser­vice to say, twitter.

Why? Because even if 1 cus­tomer thinks “that it would be AWESOME” — you’re going to spend $X hours of engi­neer­ing time glu­ing a volvo on the side of your bat­tle­ship, and unless those $X hours are com­pen­sated by the amount of money the cus­tomer is will­ing to pay (it never is) you’ve wasted time, and mud­died the func­tion­al­ity and phi­los­o­phy of the prod­uct. It’s about as use­ful as a screen-door on a submarine.

When you’re think­ing about require­ments ask your­self this: If at the start, you can not describe exactly what your prod­uct does in under a minute — you’ve already got a prob­lem. If adding this fea­ture makes it even harder to describe/encapsulate the vision and capa­bil­i­ties of the prod­uct you’re rapidly run­ning towards wronger-than-wrong.

If you your­self would not use the fea­ture: Does it really make sense? When a cus­tomer requests a fea­ture — does it make sense for any­one out­side of them? Would you be bet­ter served by pro­vid­ing an API and an SDK?

This is the beauty of things like a clean API — you can keep the phi­los­o­phy and core of the product/project clean and empower your users to build any num­ber of things they want on top of your prod­uct. Keep it sim­ple, keep it clean. Empower your users to “mashup” as they need or want to.

Think of it terms of cook­ing: If you wouldn’t eat it your­self, in all like­li­hood your cus­tomers won’t like it, at best it will be mediocre. The best chefs taste and con­sume what they cook.

Right now I’m wish­ing Brian Fitzpatrick’s keynote from pycon: “You *can* Fool All of the Peo­ple All of the Time” was online in video form.

See also: THE TECHNOLOGY OBSESSION by S. Lott

  • Wardo

    I cer­tainly can’t argue with Linus, but Steve Yegge has a dan­ger­ously one sided (and imma­ture) view of require­ments engi­neer­ing. I used to feel the same way when it came to require­ments, just a bunch unnec­es­sary busy-work that got in the way of real work. Then I started devel­op­ing med­ical appli­ca­tions and real­ized the value of require­ments. Not only will you never release any­thing that falls into the realm of FDA reg­u­la­tory over­sight with­out them, but when you are a patient, trust me, you’ll be glad they’re there.

    I think when Linus made that state­ment, specs were not as iter­a­tive as they are now. Just as the water­fall approach to devel­op­ment has gone the way of the dinosaur, so too has require­ments being etched into stone — real­ity always wins. BTW, require­ments and specs are two very dif­fer­ent beasts…

  • jnoller

    So, Steve and by exten­sion, I, am not argu­ing *against* require­ments — we’re both argu­ing against the “nor­mal” method of gath­er­ing and iden­ti­fy­ing those require­ments (and by exten­sion, fea­tures) in many com­pa­nies, starups and oth­ers alike. Steve’s idea is sim­ple: Don’t build some­thing *you* wouldn’t use.

    I don’t think any­thing either one of us has said runs counter to the idea of mission-critical appli­ca­tions. Espe­cially when design­ing those types of devices and appli­ca­tions it’s impor­tant not to muddy the waters with use­less fea­tures, ideas, or require­ments. It’s crit­i­cal to “keep to the core” — do one thing, and do it exceed­ingly well. Design one thing: And design it well.

    Do not cre­ate things you your­self — or your com­pany — you would not use. Require­ments are good — they define what you have to do, but where those require­ments and fea­tures come from is the key to what we’re both saying.

    As for water­fall going the way of the dinosaur — well, you obvi­ously haven’t worked in a lot of big­ger soft­ware teams or groups, or with peo­ple who “came to age” in that era. The water­fall method of require­ments def­i­n­i­tion is very alive and well, much to the cha­grin of many :)

    The same applies to specs — you can design a per-the-spec NFS server, but guess what? Most clients on the desk­top and server are *not* spec com­pli­ant. You will always be mak­ing con­ces­sions to clients that played it fast and loose.

    It’s much bet­ter to iden­tify your core users (of which you are one) and write the soft­ware to help and serve *them* — not the spec.

    Ulti­mately I think Steve’s post stands on it’s own: Build some­thing you love, use and believe in. Don’t build some­thing for some myth­i­cal audi­ence with a made up set of require­ments which will ulti­mately not serve them prop­erly — a prod­uct that only does 50% of what they need, 50% of the way they need and want to work will ulti­mately fail.

  • jnoller
  • http://farmdev.com/ Kumar McMil­lan

    Although I agree that “require­ments gath­er­ing” usu­ally smells of over­paid bald­ing con­trac­tors, I’ve noticed that a soft­ware project will quickly fail if there is not a clear spec­i­fi­ca­tion for how a user should use it. Rather than use the word spec­i­fi­ca­tion, my com­pany has adopted the phrase User Story. Specif­i­cally, we pull a lot of oper­a­tional the­ory from the Scrum method­ol­ogy (http://en.wikipedia.org/wiki/Scrum_%28developme…). Scrum goes so far as to say all User Sto­ries must look like this: “As a <spe­cific user> I want to <per­form some action> so that <some value is achieved>.” While it is some­times hard to get these sto­ries right the struc­ture is genius. It forces the devel­op­ment team AND the busi­ness to pri­or­i­tize fea­tures bet­ter, cut out unnec­es­sary fea­tures, and focus on deliv­er­ing soft­ware solu­tions to the user for busi­ness value. If the sto­ries aren’t in this struc­ture then they start to look more like “requirements.”

    I heard recently about a team that had a story, some­thing like “Migrate to new data­base.” This never got pri­or­i­tized in a work sprint. The busi­ness and devel­op­ers just kept push­ing it back putting other sto­ries in front of it. Then, finally some­one rewrote the story bet­ter: “As a devel­oper I want to migrate the data­base from Ora­cle to Post­gres so that the busi­ness can save hun­dreds of thou­sands of dol­lars per year.” Well, guess what, that revised story took prece­dence over all others ;)

    It’s also true about hav­ing one sin­gle vision­ary. There’s another inter­est­ing method­ol­ogy called DSDM (http://en.wikipedia.org/wiki/DSDM). They actu­ally define a role in soft­ware devel­op­ment called the “Vision­ary,” a per­son who is respon­si­ble for the direc­tion of the prod­uct. This always reminds of the Mac OS X desk­top. I read some­where that there is *one* sin­gle per­son who approves UI deci­sions. I per­son­ally think OS X has a great user inter­face and if this is true then it cer­tainly proves the impor­tance of mak­ing one per­son (not a com­mit­tee) in charge of the really hard decisions.

  • Wardo

    Upon re-reading my com­ments, I real­ize I didn’t effec­tively com­mu­ni­cate my posi­tion. That posi­tion is: Require­ments are *mostly* nec­es­sary, and the dis­ci­pline of require­ments engi­neer­ing is a neglected and mis­un­der­stood dis­ci­pline. I apol­o­gize for the *imma­ture* remark, because now I under­stand where Steve is com­ing from, and stu­pid require­ments are a huge prob­lem and more often than not con­sti­tute the major­ity of require­ments set down — I have worked in envi­ron­ments with stone tablets for require­ment tem­plates. My com­ment orig­i­nated from the col­lo­quial devel­oper pre­dis­po­si­tion that require­ments, in any form, are an unnec­es­sary bur­den and that the process needs to go away.

  • jnoller

    It’s quite alright — I too once thought require­ment were stu­pid. When I get a chance, I might work up a post on a project that I spear­headed (it was an inter­nal one) where I out­lined the require­ments, wrote the code (badly) and then pushed it upon the users. It ended well — after much pain and time.

  • CAT

    There is a lot of truth in this.
    I can­not say, who approved or dis­missed the require­ment for a trash bin at least some­how sim­i­lar to the desk­top coun­ter­parts in every iPhone 1.0 app, but both the per­son (don’t care shit, if he’s also named Steve ?;-) and this require­ment is extra­or­di­nar­ily stu­pid, too.

    In another media com­pany which tried to jump the music down­load band­wagon, a ser­vice they killed soon after Apple started drop­ping DRM I was in a project where a cou­ple of stake­hold­ers had var­i­ous meet­ings about how the search pages and “micro­for­mats” for music down­load items should be designed. A cou­ple of approaches from var­i­ous busi­ness guys and man­agers a “sim­ple” DBA or sysad­min stood up and said “This is all Bull­shit, let’s try the oppo­site approach”. And it worked just fine for us to design and imple­ment it in a few week’s time.

    I know a few sim­i­lar episodes, but this prob­a­bly meets your tagline best..

  • http://fourm.com Aron T

    Jeez, read the Myth­i­cal Man Month. Then read it again. Fred Brooks was the first to say it and he said it bet­ter than any­one since. Why peo­ple need to keep on re-discovering the obvi­ous is beyond me. FOSS projects are suc­cess­ful because they fol­low so many of Brooks prin­ci­ples for success.

  • jnoller

    No one is “re-discovering” any­thing — Yeah, this is old hat rehashed, but it still doesn’t change the fact that too many com­pa­nies, peo­ple and devel­op­ers them­selves don’t adhere to basic san­ity. You don’t need to preach to the choir.

  • http://kayley.name Andy Kay­ley

    I’m lov­ing the “volvo on the side of your bat­tle­ship” com­ment .… soo true :)

  • http://kayley.name Andy Kay­ley

    I’m lov­ing the “volvo on the side of your bat­tle­ship” com­ment .… soo true :)

What's this?

You are currently reading Steve Yegge hits a homer: Your requirements are stupid. at jessenoller.com.

meta