“Software is a great combination of artistry and engineering.” — Bill Gates
Is building software the same as manufacturing a physical product? Can you really create an assembly line for software?
In today’s world, software plays an increasingly important role in our lives.
From the apps we use on our smartphones to the complex systems that power our businesses and organizations, software has become an essential part of our daily lives.
However, despite its growing importance, software development remains a unique and challenging field that requires a different approach than traditional manufacturing.
In the book A Practical Guide to Enterprise Architecture, 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.
In this guide, we’ll explore why the manufacturing metaphor doesn’t work for software and offer insights into how software development can be approached in a way that reflects its unique characteristics.
So if you’re interested in learning more about software development and how it differs from traditional manufacturing, let’s dive in.
5 Reasons Why the Manufacturing Metaphor Doesn’t Work
The manufacturing metaphor doesn’t always work for software for several reasons.
McGovern, Ambler, Stevens, Linn, Sharan, and Jo provide the following reasons:
- Software development is much less predictable than manufacturing a product.
- Software is not mass-produced on the same scale as a physical product.
- Not all software faults result in failures.
- Software doesn’t wear out.
- Software is not bound by physics.
Use the Manufacturing Metaphor for Software with Caution
The manufacturing metaphor for software is an approach of developing software similar to how physical products are manufactured.
However, since software is different from physical products in many ways, this approach may not always be suitable. Software development is complex, involves uncertainties, and is malleable, meaning that changes can be made easily and quickly.
Therefore, it’s essential to use the manufacturing metaphor with caution and approach software development in a way that is tailored to its unique characteristics.
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.”
Software Process and Design are Less Quantitative
Software process and design are less quantitative, meaning that it’s harder to measure them objectively using numerical values.
Unlike other fields, such as engineering or physics, where calculations and equations can be used to precisely determine the outcomes of various processes, software development involves many subjective decisions that are not easily quantifiable.
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.”
The development of software involves a complex process of analyzing requirements, designing solutions, and writing code, all of which are inherently subjective and difficult to quantify.
While metrics such as lines of code or number of bugs can be used to measure some aspects of software development, they don’t always provide a complete picture of the quality or effectiveness of the software.
In addition, software design is often more open-ended than other design fields, such as mechanical or architectural design, which have well-established principles and best practices.
Software design involves making subjective decisions about how to structure the code and user interface, which can vary depending on the specific requirements and context.
Therefore, it’s important to recognize that software process and design are less quantitative than other fields and to approach them in a way that acknowledges their unique characteristics.
This may involve relying more on human judgment and experience, rather than numerical data, to make decisions and evaluate the effectiveness of software development processes and designs.
Software is an Intellectual Human Endeavor
Software is an intellectual human endeavor, meaning that it is primarily driven by the knowledge, creativity, and problem-solving abilities of human beings.
Unlike physical products, software is not produced by machines, but rather by teams of people who use their intelligence, experience, and intuition to design, develop, and test software.
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.”
The creation of software involves a significant amount of intellectual effort, including analyzing requirements, designing solutions, writing code, and debugging errors.
While computers can assist with many aspects of software development, they are ultimately tools that are used by human beings to create something new and innovative.
Software development is also a highly collaborative endeavor, requiring teamwork, communication, and coordination among developers, testers, project managers, and other stakeholders.
The success of software development depends not only on technical expertise but also on effective communication, problem-solving skills, and the ability to work well with others.
Therefore, it’s important to recognize that software is an intellectual human endeavor and to approach software development in a way that values the skills and contributions of the people involved.
This may involve fostering a culture of creativity, innovation, and collaboration, and providing opportunities for ongoing learning and professional development.
Key Takeaways
Here are my key takeaways:
- 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.
Get the Book
You can get A Practical Guide to Enterprise Architecture, by James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo , on Amazon.
Data Architecture Practices
[…] 5 Reasons Why the Manufacturing Metaphor Doesn’t Work […]