• Skip to main content
  • Skip to header right navigation
  • Skip to site footer

Shaping Software

Enduring Ideas in the Realm of Software

  • About
  • Topics
  • Best Software Engineering Books
  • Lessons in Software
  • Archives
  • JD Meier.com

5 Reasons Why the Manufacturing Metaphor Doesn’t Work

Sep 21, 2008 by JD

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

  • The Impact of People on Cost and Effort
Category: ProcessTag: Process

About JD

Previous Post:Data Architecture Practices
Next Post:Software Product Lines

Reader Interactions

Trackbacks

  1. Software Product Lines | Architecture | Patterns and Practices for Software Engineering. says:
    Sep 21, 2008 at 3:34 am

    […] 5 Reasons Why the Manufacturing Metaphor Doesn’t Work […]

  2. Organizational Structures to Support Product Lines | Architecture | Patterns and Practices for Software Engineering. says:
    Sep 21, 2008 at 6:05 am

    […] 5 Reasons Why the Manufacturing Metaphor Doesn’t Work […]

Sidebar

Recent Posts

  • Best Software Books of All Time According to a Microsoft Exec
  • How To Effectively Pitch a Business Idea (Customer, Problem, Competition, and Success)
  • Customer-Connected Engineering at patterns & practices
  • Lessons in Software Development from Eric Brechner
  • Best Practices at patterns & practices

Popular Posts

Best Software Engineering Books
Best Practices for Project Management
Best Practices for Software Development
Customer-Connected Engineering
How To Frame Problems Better
How To Pitch Business Ideas Better
How To Structure Vision Scope Presentations
Intro to Lean Software Development
Lean Principles for Software Development
The Enterprise of the Future