Slashdot | Hiring Good Programmers Matters: "Where you go wrong is that people don't actually know what they want!

I've written projects with HIGHLY detailed specs. I've talked to people high and low. I've gotten signatures in triplicate.

And, those are the projects that BOMB QUICKLY AND PAINFULLY.

The last time I tried that approach, I was told on the DAY OF ROLLOUT after 1.5 months of full-time development that it 'wouldn't work' and had to be 'totally redone'.

I screamed, bitched, complained, waved contracts, specifications and all, before spending another 2.5 months rewriting the application. (while people were using it!)

So, now I do things differently. I spend a bit of time, get a spec, and send out an email to all involved, and wait for 24 hours. Then I write it, knowing full well that it will suck upon delivery, and I make this knowledge apparent, obvious, and common.

Then, the comments come. The text is hard to read. It doesn't include N-ARCANE-FEATURE. When you click the button called 'Save', it saves it, but it's not obvious what you are saving.

Whatever. The feedback comes in spades.

So, focus on making updates quick and easy, and listen. That's the Linux way: release early, release often.

People will tell you what they like and don't like. Listen, and release an update when you add new features.

In my flagship product, I've released over 40 releases in a single year. It'd be painful, except that the product updates itself, and it takes me all of about 10 minutes to release. Really.

It costs each user about the same - 5-10 minutes, and they can do it whenever they like.

So, I release early, I release often, and I listen closely to the feedback. Users get what they want, and I get what I want. (Users' money!)"