I have seen the worst specs ever: A phonebook of descriptions, channels of content laid out in such detail that you would know exactly where which pixel should be. If you were able to read it of course.
I have also seen those very, very flexible specs. “Just make it send an e-card.. or something like that”.
The problem with specifications is that they can be too light or too heavy, and there is no way of knowing which is right for a project before you start. If you are really lucky, you work with thinking programmers who are able to correct mistakes, suggest improvements and fill in the gaps. They know the intention of the project and know what works and what doesn’t and most important: they aren’t afraid to speak up. Those people are rare, which is one of the reasons why a lot of websites and applications suck. In desktop software teams work for years on a piece of software, but on the web most projects are temporary and when it is done it is done. Not the best product matters but a cool look and acceptible coding in the shortest time possible.
The right specs differ from programmer to programmer, and one of the reasons for that is that we don’t all have the same imagination, (project) methodology, vocabulary, interest in users or even common knowledge.
Mark states it a bit bolder: there are two kinds of programmers… the assholes and the morons. Why specs matter. Some of the things he writes sound familiar, don’t they?