My Zen Arcade

Software specifications, when introduced for the first time to a company, can be a horrible thing. 

There’s the initial design of the specification document, who gets to write them, etc.

Process stuff.

But there’s a bigger problem.

The lie.

When a specification is written, and sent to development, it should be a static document.  Understandably, this isn’t always possible.  Not every company has the resources to do the kind of thorough design review best practices require, and during development you learn, change your mind, etc.  So, in a perfect world, a specification is static, but in the real world, not so much.

The problem is when a specification changes but the document doesn’t.  If you tell me to do A,B,C and then change it to A,B+1,C and don’t change the document, we are living a lie.  And mostly I’m worried about the damage the lie can do to me.  Really, I can’t win.  If I do what the designer ask, and it goes poorly, they go back to the document and see that what I did doesn’t match the specification.  If I go with the original document and it goes poorly, the designer can complain about how they made a change and just didn’t record it. 

If a design specification document is not sacrosanct, then the developer has to work overtime keeping track of things so that when people come to complain, his ass is covered.