In software engineering there have always been two schools of thought. One school feels that there is a lot to learn from manufacturing. The other school thinks that they are entirely different.
There have been 3 distinct phases in this debate:
- CMM Phase: Manufacturing has transitioned from craftsmanship to mass production – productivity and quality has improved many-fold. Software development can also benefit from such transition. CMM movement was born from this thought.
- Agile Phase: Manufacturing deals with machine, software development deals with people. Processes involving machines can be controlled precisely. People are inherently different and are not interchangeable. People communicate better face to face rather than through written documentation. From this realization agile movement was born.
- Lean Phase: Toyota revolutionized manufacturing through lean manufacturing system and dramatically improved quality and optimized cost. The core of lean manufacturing is empowered teams. Since agile movement also is based on self-organizing teams it must be possible to transplant the learning from lean manufacturing to software development. This lead to lean software development.
There is an apparent logic in all three reasoning. So, which advice should you follow? Are they compatible with each other? Before answering these questions you should look at the differences between manufacturing and software development.
Same item produced many-many time
Software is written only when nothing similar exists
Even before start, the specification of the output is clearly defined
|Incomplete & Evolving:
Not only are requirements sketchy at the beginning, but also likely to change during the development cycle
The process of converting input to output is clearly known and can be repeatedly done
There always are unknowns – in form of new technology, new interfacing requirement …
|Machine & Tool:
Any process efficiency is dependant mostly of the machines and tools used and less on the people operating it
Knowledge, experience and skill of people can make huge difference in productivity sometime as much as 1:100 between best and worst
Will this gap ever be bridged? Will software development move closer to manufacturing?
I doubt it – here is why.
Repeatability vs. Uniqueness:
“…Every advance for the future state of the world requires the presence of software yet to be written…” – Grady Booch (here)
You are never going to write software which already exists!
Well-defined vs. Incomplete & Evolving:
The authors of the Agile Manifesto understood it when they wrote:
“…Responding to change over following a plan…”
“…Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage…”
Software is about advancement … software is about new idea … not all new idea succeed. Trial and error cannot be avoided.
Known vs. Unknown:
“…There is no end in sight to the deluge of new technologies being delivered to market…”
“…If there is any one concept or idea that software developers must absolutely comprehend, it is this: it really is okay not to know it all…”
The rate of technology change is accelerating. Technology options are increasing. Current software, for all practical purpose, has infinite features! The world is becoming more and more interconnected. Hence, software developers of the future will need to handle more unknown, not less.
Machine & Tool vs. People:
“…Most CTO’s realize that The Pareto Principle applied to IT staff means that 20% of your people are delivering 80% of your entire team’s bottom-line value…”
“…The difference between the extremes has been reported as high as 100:1…”
Unless we can find a method of completely automating the process of software writing, the dependency on people will remain. The chances of automating the process of software development in foreseeable future look remote.
What can we conclude from this?
Reject all idea which is derived or borrowed for the purpose of managing predictable processes.
Accept all idea which helps you to deal with unknown and uncertainty.