If software specs are so important, why do so many software teams skimp the most on specifications? Here's the politically incorrect skinny.

• It's very difficult to do it well
• It requires fighting with other people for their time
• Those people you fight with don't think you listen to them, so they don't want to help
• It requires time and money that managers don't want to spend
• Nobody finds it very entertaining, so they are never "in the mood"
• Perception is reality, and creating software, any software, is perceived as progress. Creating documents is not.

We all do this. We all skimp on specifications. To what degree we skimp is the differentiator. For most organizations, about 50% of all software projects fail. Projects fail for lots of reasons, but a consistent theme in post mortem analysis is inaccurate or incomplete software specifications. Is there truth to this, or is it just easier than saying our ideas suck? If there is truth though, we should conclude then…

Improving specification activities is the single best way to improve your software development project success probability.

And this should make logical sense too, since no matter how good you are at creating software, if you are creating the wrong software, it's irrelevant. But… you could also logically conclude that too much effort in specification is also bad. After all, you do have to eventually build something. So seek to find the balance, but don't skimp.

Everything in Software is Iterative

I do not think that it is possible to fully specify a software product before it is built. And most people agree with me too, as nearly all respected software methodologies involve some level of iteration.

Spec, Design, Build, Test. - Do it over again until you run out of features to add or money to spend.

Everyone does this. The primary difference between methodologies is merely the size of the iteration. Some like them big (think waterfall), some like them small (think agile). But regardless of iteration size, are your spec docs changed during an iteration? Are spec changes controlled? Here's a test to help answer that question. When you finished your last iteration, did your specification match the product? If it does, it was either a really good spec or it was alive.

The Difference that a Living Spec Makes

If your spec has been properly maintained, then it is alive. It's a living document. It has an owner. Someone on the team who actually cares about it enough to feed it, water it, and make it grow. When you update a spec, then design and build against the change, your changes are more thorough. That's because when you open the spec, you are again immersed into the application as a whole, not just the specific issue that brought about the need for a change in the original spec. The cross references and related functionality are again brought to the forefront of your mind and you start to analyze the change in its entirety and how it affects all of the application stakeholders.

The importance of keeping a living spec increases with the size and complexity of your software. But even if your team is me, myself and I, you will create better software if you write specs and maintain them throughout the life of your application.

So don't neglect your specs! Give that doc a pulse and you will end up with better software.

Brian