This chapter is from the book
This chapter is from the book
This chapter is from the book
2.6 A Software Blueprint
The goal of any software planning effort should be to analyze the business requirements and translate that understanding into a specification that facilitates the development process as efficiently as possible.
If you don't know where you're going, it is difficult to get there and impossible to know when you have arrived. Most planning efforts proceed by fanning out and mapping everything as they go, hoping that the end result will include a route to the ultimate destination. They craft their planning deliverables in ad hoc fashion as they go. The functional specification ends up becoming an apparently random maze designed to bewilder and befuddle the developers.
This problem is inevitable when you don't have a clear planning goal defined from the onset. The software blueprint defines a tangible goal for the planning process in the same way that a Form 1040 defines a tangible goal for the tax preparation process. It should provide developers with exactly the type of information they need to construct a program, in the same way that a house blueprint provides the construction crew with exactly the information they need to build a house.
While analogies and comparisons are never perfect, they do help make ideas more familiar and meaningful. House building is probably the most commonly cited analogy for software development. There certainly are a lot of similarities, but there are a lot of differences as well.
Software development is a very customized process. However, house building can also be highly customized. The elements that make up a house are fairly simple. Floors, walls, doors, and windows make up every house. Likewise, there is a fairly simple set of pieces that make up every software project. If we can arrange these pieces into a standard blueprint that organizes them, then that blueprint should be all we need to describe most software projects effectively for the builder's purposes.
A software blueprint is a single, simple, and standardized format to specify software requirements. Builders couldn't be expected to construct a new house without a blueprint, yet software developers are routinely asked to build software without an equivalent blueprint to work from.
Most software specifications do not even begin to serve as an adequate blueprint. They are designed to serve many purposes, but not specifically to meet the needs of the developers. They do not provide developers with the exact information they require, at the necessary level of detail and consistency, and in an easily accessible format.
If software were a house, here is how the usual planning and construction process might proceed:
The salesperson initiates contact with the buyer and tells the project manager what the buyers are prepared to spend.
The project manager has several meetings with the buyers. He gets a general idea of what they are looking for and prepares a Vision Document documenting the problems with their current house and specifying what size house the clients need. The Vision Document cites the projected cost (coincidently just a bit more than the buyers said they were willing to spend) and describes how much they will gain compared to their current home.
The homeowners think that sounds pretty good, so they meet with the house designer every day for the better part of a year discussing what kind of colors they like, what kind of dimmer switches annoy them, and the hours of the day when they use the bathroom and kitchen.
The house designer collects all the information, including tax returns, magazine pictures from Better Homes and Gardens, and poetry composed by the homeowners to describe their vision of the new house.
The house designer prepares some usage scenarios which summarize the times that the homeowners are likely to use the garage door opener as well as some transition diagrams illustrating in detail their expected traffic patterns in the new house. He bundles these up with the magazine pictures provided by the prospective owners, and hands all this to the construction supervisor.
The construction supervisor, already told what the house will consist of, what the buyers will pay, and when they need it completed, goes about the task of fabricating a construction plan and cost breakdown which reflect the timeline and total cost already predefined. The detailed estimate, tailored to meet the predetermined cost, reassures the steering team that their initial estimates were right on.
The construction supervisor goes about gathering a construction team whose members laugh or cry, according to their particular nature, when they are told what the house will include, what it will cost, and when they are expected to complete construction.
The construction supervisor hands off the house plan to the construction crew. In due course, the crew sets about to somehow build a "bedroom with two doors" and a kitchen that "radiates warmth" as they understand it from the documents they were given.
The management team, distracted with planning future houses, doesn't pay much attention to the builders for a few months. The homeowners are too busy at their current jobs to offer much information. After all, they already took too much time off for all that earlier planning.
The builders aren't sure where those two doors in the bedroom should be. They ask the planner and he tells them that the information is right there in the owner's childhood diary. The builders give up and put one into the hall and one into the bath.
Finally when the house is nearly complete, the homeowners make a walkthrough. They list about 179 first pass changes, citing the fact that it clearly says in the wife's diary that she always wanted a door to the patio from her bedroom. Oh, by the way, where IS the patio that was inferred by that passage?
The construction supervisor is sacked for not including the patio, and the crew, already far over budget and months late, works far into the night to make the changes.
That is pretty much the typical scenario in the software business. Needless to say, no home construction company could survive very long if it operated this way. In reality, the life expectancy for software firms is not high.
So how can this scenario occur so frequently in the software industry? In fairness, creating software is not as straightforward and clean-cut as building a house. There are many more variables and far fewer standard materials and methods. Yet, there are many basic lessons from home construction that seem to escape the notice of software builders.
First, you can't promise the customers exactly what they want for exactly what they would like to pay. Sure that may be a strategy for getting a sale, but not necessarily a formula for running a successful business.
Second, you can estimate the cost of a house pretty well just by knowing the square feet enclosed. Based on only that one metric, you can tell the owners within a narrow range what their house will cost, only adjusted for any high-quality extras they might want. There is no such square footage metric for software, so the estimation process is infinitely more difficult.
Third, you can't build a house based on traffic flow diagrams and room modeling charts that describe the house indirectly at best, with required details buried inconsistently among all the superfluous information. The builders of houses require a clear blueprint designed specifically to meet their needs. Yet in software development, more complex in many ways, we set about our jobs without an analogous blueprint.
Yet the level of complexity is really quite comparable. Software blueprints can be far more simple, standardized, clear, and efficient than the documents we normally produce in their place. What elements would a comparable software blueprint contain?
A Data Dictionary to establish a clear, unambiguous vocabulary
Mockups or prototypes to lay out the floor plan of the screens
Pseudocode to unambiguously define operational logic
Precise definitions of data elements so that the forms and databases can be constructed
Logic to clearly define the rules for data translations
Narratives to describe relevant background
With such a blueprint in hand, developers normally have all the information they need to produce software quickly and accurately the first time, with minimal input from the business experts. Builders of a house don't need to understand a lot about the day-to-day activities of the future owners. Likewise, software developers don't necessarily need to understand a lot about the client's business. The reason that many experts feel that greater understanding by developers is a requirement is because the developers usually do their own research or use their own judgment to compensate for incomplete project plans.
Obviously, you can't take disorganized output generated during the planning process and call that a blueprint. A blueprint has very specific characteristics. It distills other information and presents it in a logically complete and consistent format for use by the software builders.
Blueprint format has to be the expressed goal of all your efforts right from day one. The specific format of that blueprint must be clearly known from the start of the process, and all efforts should be dedicated to getting to that blueprint as efficiently as possible. You can't start with all the things you have been generating in the past and create a blueprint from it. Also, you can't get to a blueprint by accident. Nor can you create a good blueprint as an afterthought.
To produce a good software blueprint, you must engineer a planning process that begins to develop that blueprint from day one. The curious thing is that if you do so, that process can be considerably more simple and efficient than your current strategies that achieve far less useful results.