Stop Using Specs as a Weapon

One of the things I've been working on is specs. I think of myself as being kind of good at the functional spec -- I'm not always clear on the precise technical means to accomplish the things that people want to do with systems and services but I'm very articulate about what we're trying to get done. I love writing specs, and I find them to be useful tools to

• prompt questions from the non-technical customers and the programmers alike, all of which can make the project better
• make it clear what we're doing and what we're not doing
• avoid heartbreak and disappointment at the end of the project

Specs are great. But in the wrong hands, they can be deadly. Like when they're treated as a legally binding contract and are invoked to defend programmers against dissatisfied customers: But dude, you didn't say you wanted it to record the transaction in the database, the spec says "accept transactions" and the system doesn't throw an error message on submit, so it's working as we defined. Uh. Right. Don't get me wrong, customers are guilty of throwing the spec up in the programmers' faces, too.* Maybe you can't have a helicopter, and maybe you didn't hear the people say that a helicopter wasn't going to work.

So as the spec-gal, you also need to make sure that the customers and the programmers know that the spec is a living document, and features may be added or removed, but everyone's gotta know about it and agree to it.

*Yes, I know this conversation isn't about a computer programming project, but I think the common elements are easy to see: unrealistic expectations, the technical execution staff going off and not communicating with the customer thoroughly, with a hearty dose of mental illness. Pretend instead of "helicopter" they're talking about "dynamic form handling widgets" or somesuch.