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. Horseshit. 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.
See also: THE TECHNOLOGY OBSESSION by S. Lott