Specs fill communication gaps

You may very well not need a spec for your software project. I had a recent conversation with a friend in a very small (3-4 person) company, building their first online product, and he said his sole developer was going off to write a spec. This raised alarm bells with me, as I saw it as a tactic for procrastination.

Specs are useful for filling a communication gap. That gap may be one of team distance (the BA to the vast army of developers, too many to speak to all at once), or time distance (we’ll write this down now, because we may forget it in 3 months’ time when we start the work), or organisational distance (we’re going to give this to you, third party company, because this is precisely what we want you to build for us). There will be other examples.

But if those gaps don’t exist then you probably don’t need a spec. In particular, if you have four people in the company, and you don’t yet have any software, and are still validating your product idea, then a spec isn’t going to be useful. There, the best thing is to write the smallest thing you can, try it out, and repeat.

None of which is to say that all documents are bad. Far from it. It’s a good idea to write down a strategy (lest you forget it in the heat of the moment), an architecture (which you should aim for but may want to adjust), and some principles of various kinds (UX, engineering, product, etc).

But a spec is too often a document we could do without.