Lean Wisdom: Software Design Spec is Muda

Goal of any software is to create customer value. Aim of Radical Programming is to create order of magnitude improvements in returns on the efforts required to generate that value. There are two obvious ways of achieving that: increasing productivity and reducing waste. 

Waste reduction is an effective way to increase profitability. The lean thinking originated at Toyota Production System. It is based on the idea of reducing three types of wastes viz. muda ("non-value-adding work"), muri ("overburden"), mura ("unevenness").

There is nothing so useless as doing efficiently that which should not be done at all. 

-        Peter F. Drucker

Mistaken Identity

For a long long time our industry has mistakenly borrowed construction metaphors. Result is our desire to write up a design document or complex graphical representations like UML. 

In other industries like mechanical production or civil construction, we actually need physical (hard) material to build each new unit. This production requires workers, materials, tuning assembly lines, takes time and costs money. There is an inventory of physical things to manage. In a nutshell, production is a big deal. Mistakes in design cost money, rework and lots of pain. It is not simply a matter of undo a checkin it is lot more painful. If design of your car chassis is wrong, you'll actually have to recall vehicles and melt the car back into the steel and start over again.
Now if you could find the problem before going into the production all you have lost is just time required to design that thing. That's why proper design is important and why 'building' is lot bigger deal than designing. 

Compare all this to how we 'create' software: We start our "build' which in turn calls compilers. Once we have binaries we then 'publish' them- Ready for people to download (or copy) and install. It probably took us only a couple of minutes. From this point of view software construction is free! Remember we don't ship code, we ship binaries! If you found the problem before going into production all you lost was developer's time. If you have found a problem after production release you can release a critical patch - it won't be fun but you can at least fix it. Building software is nowhere close to building a car or a dam or a space shuttle or a microprocessors. Just type in make (or ant or nmake) and you have 'made' the software.

Blueprints  

Whenever we think of a design it reminds me of a blueprint. In 'hard' engineering designs are important. They really are. You can't argue with the fact that blueprints are absolutely essential to construction. Say we want to build a house.  I hope you agree with the sentences in bold italics (Remember these as you read because we are going to see if exact statements are equally true with software design.)

• We want to make sure the architects and structural engineers we are hiring are professionals. That they have tested their design. That they have stress tested it for earthquakes, winds, snow on the roof. That they have made sure that it adheres to the building code.So on...design can be analyzed using different models.  
• Once they create a viable design or a blueprint, from that blueprint they can estimate how much material they need. Project engineers can then create a project plan Eg.When to start laying foundation, when structure is erected, when flooring is done, when to paint etc. Each step takes time and really can't start before it's prerequisites are complete. In theory you can build a house one room at a time but that doesn't make much sense. So they plan the work for the entire house. They will then hand the blueprint off to the contractors, who will actually build them. Things can not be built randomly we need to understand dependencies between various stages.  
• Going into Production is a big deal. It is a point of no return. Having good design before hand is important. Because once you start building, you can't correct design defects.
• What about Design changes before going into production? They can of course change the design thousands of time before going into production. If something is wrong with the design like there are too many stresses in the beam or something like that they can change it. They can go through iterations until they resolve most of the engineering problems. There can be thousand iterations with the design itself and no one will complain, in fact it is encouraged.  
• Again we want to customize our house. You know what I would like? I would love to see a 3D model so I can make suggestions. Shuffle rooms around, move columns around , change where I put doors and windows. Most of the times we can accommodate these things by changing design. Early in the game, showing mockups or models (i.e prototypes) to the customers is helpful.  
• But at some point I need to stop and sign off on a final design. We now have a blueprint we can use to 'produce'/ 'build'/'construct' dream house. We need sign-offs only because construction can not begin before we finalize design.   
• Now what is the best way to communicate a design ? Write up a design doc ? No! You draw a blueprint. Contractors, electricians, interior decorators, inspectors all communicate though blueprints. Why blueprint? Because that's the most natural way to communicate 'design information'. It is precise and "executable". Of course you must be able to read and understand blueprints but then everyone in that profession can do that. With medium like that you don't need yet another document describing the blueprint or design. Blueprint (i.e. Design) itself is actionable, quantifiable, measurable - it is executable.   

But dude, for software engineering - Code is the Design!
With the modern object oriented programming languages like Java, C# or C++, a well commented code is like a blueprint. It is self explanatory. You don't need a separate design document. Software Design Specification document is a Muda (waste) that needs to be eliminated.

• It wastes valuable resource - developer time to write and review it.  
• It is often stale, out of date and out of sync with the actual implementation.

Assuming you write modular and component oriented software, all you need is a very high level overview of  what each module/component does and the actual code for it. No need for design spec! If act of coding itself is a design then all the following is still true. Except one thing production is not at all a big deal.

• design (aka code) can be analyzed using different models. Eg. static analysis, code inspections, memory and time complexity, 
• Things can not be built randomly we need to understand dependencies between various stages.  Yes indeed. That's why we right complex make files and build scripts. I'm not cheating here. We really do need to understand dependencies and a plan to 'build' software. It just happens that actual building is cheap.
• Going into Production is a big deal. It is a point of no return. If production is 'building'- no big deal. If it means 'deployment', Yes big deal - but then we are not going to release software until we thoroughly test it.
• There can be thousand iterations with the design (aka. code) itself and no one will complain, in fact it is encouraged. Refactoring? TDD?
• Code (i.e. Design) itself is actionable, quantifiable, measurable - it is executable

We should not waste time writing design documents. We should start coding. Because CODE IS DESIGN