Comments on: The Slow Death of the Technical Specification http://dd.dynamicdiagrams.com/2007/11/the-slow-death-of-the-technical-specification/ Dynamic Diagrams' take on the world of visual explanation, information architecture, design, and technology Thu, 19 Jan 2012 19:41:06 +0000 hourly 1 http://wordpress.org/?v=3.1.1 By: andrewgilmartin http://dd.dynamicdiagrams.com/2007/11/the-slow-death-of-the-technical-specification/comment-page-1/#comment-56 andrewgilmartin Sat, 01 Dec 2007 20:19:02 +0000 http://dd.dynamicdiagrams.com/?p=408#comment-56 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 pager 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 what the customer wanted. The weakness of the paper implementation that it does not define the coded implementation. The construction industries have "as built" blueprints. This 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. 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 pager 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 what the customer wanted.

The weakness of the paper implementation that it does not define the coded implementation. The construction industries have “as built” blueprints. This 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.

]]> By: Simon Dessain http://dd.dynamicdiagrams.com/2007/11/the-slow-death-of-the-technical-specification/comment-page-1/#comment-51 Simon Dessain Wed, 28 Nov 2007 11:05:14 +0000 http://dd.dynamicdiagrams.com/?p=408#comment-51 This is a valid position to hold but it risks understating a crucial element in many services -- the transaction processing layer. IA, as a discipline, has too often treated the portion you describe as 'process flows (for explaining complex transactions)' with too light a touch for the inherent complexity involved. Whilst I dont desire to read any more 100 page 'specs', I do need to know specifically, and in advance, how transaction processing will be managed. This is a valid position to hold but it risks understating a crucial element in many services — the transaction processing layer. IA, as a discipline, has too often treated the portion you describe as ‘process flows (for explaining complex transactions)’ with too light a touch for the inherent complexity involved. Whilst I dont desire to read any more 100 page ‘specs’, I do need to know specifically, and in advance, how transaction processing will be managed.

]]>