Don’t Do Dead Documents #

Eliminate unnecessary paperwork #

Avoiding functional specs is a good start but don't stop there; Prevent excess paperwork everywhere. Unless a document is actually going to morph into something real, don't produce it.

Build, don't write. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document. An actual interface or prototype is on its way to becoming a real product. A piece of paper, on the other hand, is only on its way to the garbage can.

Here's an example: If a wireframe document is destined to stop and never directly become the actual design, don't bother doing it. If the wireframe starts as a wireframe and then morphs into the actual design, go for it.

Documents that live separately from your application are worthless. They don't get you anywhere. Everything you do should evolve into the real thing. If a document stops before it turns real, it's dead.

No One's Going to Read It #

I can't even count how many multi-page product specifications or business requirement documents that have languished, unread, gathering dust nearby my dev team while we coded away, discussing problems, asking questions and user testing as we went. I've even worked with developers who've spent hours writing long, descriptive emails or coding standards documents that also went unread.

Webapps don't move forward with copious documentation. Software development is a constantly shifting, iterative process that involves interaction, snap decisions, and impossible-to-predict issues that crop up along the way. None of this can or should be captured on paper.

Don't waste your time typing up that long visionary tome; no one's going to read it. Take consolation in the fact that if you give your product enough room to grow itself, in the end it won't resemble anything you wrote about anyway.

—Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide