Specifications considered harmful

Open source, the web, and super-high-level scripting languages have conspired over the past few years to make the idea of writing specs for software development sound downright medieval. Like if you wrote a spec, you'd not only insult the intelligence of your team, but David Heinemeier Hansson himself would come over to your office and give you a lobotomy with a garden hoe.

Knowing what you're dealing with

Modern abstractions have removed so much complexity from writing software that a common theme now is that writing good software is the same as designing good interfaces. This is true (at least initially) for many consumer web apps like to-do lists. Nothing gets you to a better interface faster than getting the real thing going quickly and then iterating. But what about moderately complex software? Software that is more than a simple interface to a database for CRUD operations?

When in Rome

There are a lot of bad reasons to write specs, but there are two really good ones in the right conditions.

Good Reason #1: You can't fit the problem into RAM

Some problems are too complex to hold in your head at once. Not just the implementation, but the user workflow, the business rules, and the assumptions that aren't obvious and need consideration. For problems like these, we need a spec for swap space. A good spec should:

• Provide an overview of user goals
• Expose the feature list through use cases. Specifying tasks from a goal-driven perspective, not from an interface-driven perspective
• Specify business logic and calculations
• Provide sound footing for developers when they need to come up for air
• Describe a product that helps users have an I Rule Experience

Good Reason #2: You need leverage

For all but the biggest marketing budgets, developing a product needs to be more strategic than tactical. Yes, you do need to actually get your product built, but with the amount of competition in most markets, that isn't even table-stakes. You need a way to break through. And breaking through requires a WOW factor. Products with WOW factors are built by Someone With Vision, not by a committee. And because complex projects are too big to be built by your visionary alone, having them write your spec is the next best thing to having them build it. Without a spec, the practical effect of iterating with a team is to design by committee.

How to mess up this advice

Of course, it follows that having your spec written by a committee is the last thing you'd want to do. You'll end up with software's version of a bad public art project. Or Microsoft's version of the IPod.

Fig 1: Zune "production" process.

In the next installment, we'll look at what makes software products good, and how we might use a spec to build a visionary product.