In my last post, I talked about why it’s really hard to produce a software specification before you start work that is as complete as the blueprint you would use to guide the construction of a building. Today we will discuss why it’s also impossible.
Let’s review our building blueprint example from another angle. After the blueprint is completed, just about any competent builder can use the blueprint to construct the building. Carpenters know what dimensions the house and rooms should have, roofers know how many square feet to roof, etc. In addition to knowing what work needs to be performed, builders also know exactly how much of each material will be needed. Although the construction may take place over several months, the builders will have a precise estimate of what the costs of construction will be. The developer who hires the building contractor not only knows what it will cost, but also is quite certain that as long as a competent contractor is employed the finished product will be pretty much the same.
Let’s now apply this example to a software project. Instead of a building at completion, we have an executing software system. The system is not built by a building contractor – it’s built by the compiler. Although it may only take a few moments to build, the end result will be close to identical regardless of which compiler we use. …say, wait a minute! If the builder is the compiler, then that means the blueprint is the source code.
We just put our finger on a fundamental confusion. Software developers are not builders in the sense of carpenters building a building. They are more like designers designing the blueprint. Their work product is not the finished product, but a specification for the finished product. Therefore, by definition, you cannot complete the software system specification until you complete coding the source code.
So what do we call that document we were referring to as a software specification? It’s also a specification. In fact, it’s a specification for a specification.
The artifacts produced by a traditional waterfall software project are in fact all specifications that stand in a “specification for” relationship with the next in the series.
That is, design docs are specifications for source code, functional specs are specifications for design docs, and so forth. Doing software development like this is like playing a particularly convoluted and abstract form of telephone – you know, everybody in a circle whispers something quickly that is hilariously misunderstood at the other end. Except that sometimes on a software project it takes a year or more to get around the circle, and by that time nobody thinks the outcome is very funny.
Developing software iteratively and incrementally the Agile way does not result in a big surprise at the end like playing telephone in a waterfall project does. Even so it’s usually a lot more fun.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.