What software development should NOT learn from manufacturing

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:

  1. 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.
  2. 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.
  3. 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.

Manufacturing 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:

Todd Anglin in his very interesting post The Future of Software Development states:

“…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:

Daiv Russell, in the article Hold On to Your Top Performers, states:

“…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.

15 Responses to “What software development should NOT learn from manufacturing”
  1. Edward says:

    I believe you have made the mistake many people make. Agile is based on the Toyota Product Development System (designing new models etc) not the Toyota Production System (manufacturing). Easy to do as they are so similarly named.

    Essentially yuou have created a straw man argument against Agile/Lean since you are comparing manufacturing to software development rather then product development to software development.

  2. walter says:

    Great post udayan

  3. Rahul says:


    Much of what is done in the software services industry is not really greenfield development, but rather application support, maintenance and enhancement. This part of the industry is highly amenable to cross-apply the mnufacturing experience. In fact the more one tries to treat the activity is special, the less organised, reliable and cost-effective will it be. Incidents get repeated often, and hence benefit of re-use and predesigned solutions, etc and all the concepts of group technology and sharing and process design, etc, all can have direct impact on the quality, reliability, consistency and cost effectiveness of this part of the application services space.

    When it comes to pure greenfield application development, your thoughts may have more applicability, hoever even here there is plenty of applicability of industrialisation techniques to drive up productivity and shorten cycle times and development cost. Name one software engineering best practice and you will find a similar concept which has been used in the manfucaturing sector for years. Does that exclude the role of cretivity? No. But softeare development is NOT JUST about creativity. Mostly it is about using a well defined approach to document and then develop pretty well defined application functiality.

  4. Steve Zhang says:

    I don’t think software industry is 100% unpredictable, I don’t believe that manufacturing is 100% predictable either. In manufacturing industry, there still lots of unknown and uncertainty to handle, for example there would lots of new model cars comes out, and who can predict that what the next generation of iPhone looks like? In software industry, there are lots of predictable factors:
    1. Most companies or developers will just focus on specific domain area, at the beginning, there are lots of unknown, but the more you work in this area, the more you understand, and the more predictable;
    2. Currently I don’t believe any one like to work from scratch, we still rely on a specific platform, API, etc, these stuff are repeatable, design pattern is another repeatable example;
    3. If software industry is totally unknown and unpredictable, why we emphasize on software reuse? Software reuse will be useless if it is unknown and uncertainty. I think software re-use rely on the predictable and repeatable things in software:
    API => code reuse
    design pattern => design reuse
    Agile => process reuse

    4. Actually software industry already borrow lots of concept from manufacturing , for example:
    software component, interface, design patterns, which are directly borrow from construction;

    I will say the job in software industry is use what you know to solve what you don’t know, I don’t think this is much different with other industry.
    I don’t agree with your conclusion, I don’t think software is so special that we can not borrow good ideas from other industries. I would say the reason of why software development is so complex is software industry is still young, this industry is not fully mature or fully “professional” yet compare with manufacturing, that is why we still need to learn from any other industry, including manufacturing.

  5. Great post.

    However – your conclusion is all binary exactly what Don warns us about.

    Some software development processes are in fact predictable and can benefit from non-agile principles.

  6. Manvendra Kumar says:

    Udayan, Indeed very nicely presented. I too believe with the essence, software development is more of an collaborative art than a science. None of the methodology can bridge the gap between a good and a bad software developer although great attempts has been made to fill this gap by Industry Leaders building drag and drop IDEs and standard reusable components. And as you stated it is the highly dynamic nature of unique requirements that make software development different from manufacturing. Actually it is the product inception phase that very much resembles software development cycle. But the tragedy is there is no mass production/assembly life cycle in software development. As soon as a software development life cycle is completed either there is no mass production required or if there is one (in case of off the shelf) there is nothing as compared to manufacturing.

  7. Dan George says:

    The drivers to systematic development in manufacturing hard goods are logistical: inventory, distribution, tooling, (re)production rates/lead times. The drivers for systematic development in software will be complexity, complexity and complexity. Logistics are cheap for sw and creation cost is dominant. Nonetheless, a free market demands value to increase and cost to decrease. Shall we simply utilize more of those 100:1 producers and pay them less? Show me where they are and I’ll put them right to work. Realistically, with a pool of 6 billion people, there still are not enough of those talented individuals to meet demand. Reuse will be brought to bear and it will depend on predictability of the reused parts. Characterizing functionality is the purpose of specifications and requirements. Economics will drive software development process more and more toward engineering.

  8. Lata says:

    The entire ISO is based on how we can make software development predictive. The CMM upto Level 3 is also the same. Only in Level 5 they have tried to introduce innovation, but at a very small level.The challenge for software development vendors would be to somehow marry the uncertainty which is always there with predictability so that they can ensure successful projects which are not people dependent. And customers also inherently want predictability and the comfort zone of vendors telling them that they know exactly how to handle their requirements and deliver finished products within the stipulated budget. This is a very tall order and hence the large number of failed projects.

  9. Alireza says:

    Very Nice post, thanks for sharing, actually I think the big challenge are peoples, peoples are not resources like machines. In the new economic age, there is movement to focus on people and on your team. And many different scientific domains help us in this regard such as cognitive science, Human Behavior, Psychology and others.

    In fact the old way of management (command & control) will not work for now, and I think we need leader not manager. The great leader make each player star and unique player. The leadership is defined as how we can use our player team as much as in efficient & effective manner. This is very important point which make difference between good & great leader.

  10. Mark Graban says:

    You’re right to question which approaches and methods are transferable to software. You don’t directly copy methods, you can borrow philosophies. Root cause problem solving, iterative process improvement, and engaging all employees in a trusting blame-free environment, those aspects of lean are pretty universal.

    I’ve seen the transition from manufacturing to healthcare, myself. You can’t copy all tools.

    By the way, most factories do not, actually, crank out thousands of the same thing. That’s a gross oversimplification of the manufacturing world, I’d say.


  11. Siddharta says:

    Agreed, and Don made this point over many times during his talk – there are some good things to learn from lean, but its just the first peak on the range. The focus on flow and small batches is something that translates very well into software development. Other assembly line analogies may not hold up very well.

Check out what others are saying...
  1. […] Software development is a bit different, since we developers can design and code at the same time, while in an assembly line none of the workers are designing the product. In software development, several different phases can be overlapped and even mixed together. Yet, comparing software industry with just the “assembly line” part of manufacturing industry may be not the fairest choice. Yet, some writers go on using exactly this analogy. […]

  2. […] This is not the first time that I have encountered this criticism- that software is “people centric” and hence the focus should be on managing people and not the deliverable. The root cause of this observation goes much deeper- that somehow, software development is something very unique, that it is not similar to other engineering disciplines, that it should not emulate manufacturing. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: