5 Reasons Why the Manufacturing Metaphor Doesn’t Work

2
1016

Is building software the same as manufacturing a physical product?  Can you really create an assembly line for software?   In the book A Practical Guide to Enterprise Architecture (Coad Series), James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo write about how you should use the metaphor with caution.

Use the Manufacturing Metaphor for Software with Caution
McGovern, Ambler, Stevens, Linn, Sharan, and Jo write the following:

Before dropping everything and setting up an assembly for creating software products, it should be noted that the manufacturing metaphor for software development should be used with caution.  The manufacturing metaphor for software development has been around for awhile.  In some respects, the metaphor works.  Shared components, process, and infrastructure will increase productivity and quality.  However, a car designer has to work in the physical world.  He or she is bound by physics.  It is relatively easy to measure the roll-over potential of a vehicle based on the center of gravity and wheelbase.  It is also obvious that a car with four wheels is better than a car with two wheels.  These properties are easily tested, and quantitative evaluations can be used to compare different designs.  Physical systems can be measured and compared using quantitative methods in an objective fashion.

5 Reasons Why the Manufacturing Metaphor Doesn’t Work
McGovern, Ambler, Stevens, Linn, Sharan, and Jo provide the following reasons:

  1. Software development is much less predictable than manufacturing a product.
  2. Software is not mass-produced on the same scale as a physical product.
  3. Not all software faults result in failures.
  4. Software doesn’t wear out.
  5. Software is not bound by physics.

Software Process and Design are Less Quantitative
McGovern, Ambler, Stevens, Linn, Sharan, and Jo write the following:

Software process and design are less quantitative (measurable with statistics) and more qualitative (measurable with descriptions).  Qualitative analysis requires analysis and judgement based on contrasting and interpreting meaningful observable patterns or themes.

Software is an Intellectual Human Endeavor
McGovern, Ambler, Stevens, Linn, Sharan, and Jo write the following:

The creation of software is an intellectual human endeavor.  Creating good software relies on the personalities and the intellects of the members of the teams that create it.  When applied to a different team of developers a process that delivers great software for one team of developers may fail to deliver anything at all for another team.

Key Take Aways
Here’s my key take aways:

  • The metaphor works in that you can improve productivity and quality with shared components, process, and infrastructure.
  • The metaphor does not work in that software design and process are less quantitative than manufacturing.
  • The metaphor does not work in that software does not share some of the same boundaries or considerations as the physical world.
  • Creating software is an intellectual human endeavor.

My Related Posts