The "The Slow Death of the Technical Specification" is another reason why so much slipshod work is passed off as finished work. Preparing the technical specification is an initial and thorough implementation of the work on paper. The coded implementation is the second implementation based on the strengths and weaknesses of the first paper implementation. As Fred Brooks says, plan to throw one away; you will, anyhow.
A work needs to be reviewed. The customer needs to know that they are getting what they asked for. How do you review a working implementation -- a web site, a desktop application, or an infrastructure? How do you review a paper implementation? People have been developing the skills and using the tools necessary to review a linear presentation of a work since secondary school. A very rare few people have the skills or tools to review a working implementation. Not having the written specification is short changing both the customer and the supplier. The customer gets something they are not in the position to review and the supplier is in the position of not knowing if the implementation is what the customer wanted.
The weakness of the paper implementation is that it does not define the coded implementation. The construction industries have "as built" blueprints. These are the original blueprints with annotations detailing the differences from the design and the construction (i.e. implementation). Software needs these too. We just don't have them yet.
Unfortunately, I have supplied much software without initial or even afterward technical specifications. Hardly great moments in a software development career.
