Analogy Between Programming And Manufacturing Discussion

Discussion moved from AnalogyBetweenProgrammingAndManufacturing:

Many manufactured products now have significant software content, e.g. appliances.

Most manufacturing organizations do BOTH design and assembly of physical products.

Similarly, most programming organizations BOTH write code and compile it.

Therefore, this analogy compares the full life cycles of programs and manufactured goods, including both "design" and "compiling" / "assembly".

The analogy applies, but only if you equate creating software with the design process; the actual manufacturing process is completely automatic. See also TheSourceCodeIsTheDesign.

(Please feel free to refactor, delete, and/or change the meaning of the following thoughts. As originally written, their author thought they were jumbled, confused, and likely to have errors. Also, please don't let this editing note change (if or) how you would edit the rest of the material on this page.)

Some thoughts about this comment:

The phrase "creating software" can be defined 2 ways.
- One definition is somehow limited to a "design process". The comment uses such a limited meaning, but the limitation is unclear.
- The second definition includes the whole process: both "designing"/coding, and compiling/interpreting/testing/demoing. This broader meaning was the original intent of the AnalogyBetweenProgrammingAndManufacturing. (In this bullet only, "designing" has the waterfall definition.)
The term "manufacturing" can defined 2 ways.
- One definition includes just physically making things. This limited meaning is used in the comment.
- The second definition includes the whole process: both designing the thing(s), and making/inspecting them. This broader meaning was the original intent of the AnalogyBetweenProgrammingAndManufacturing.
As noted in the AnalogyBetweenProgrammingAndManufacturing, the "design" specifies not only the product, but (less obviously) also the process to make the product.
- A programmer makes many choices about how the software will be "made", either explicitly, or by default:
  - The language(s) of the source code.
  - Whether to use a compiler or an interpreter, or a combination of the two.
  - The specific compiler / interpreter / IDE.
  - The compiler (etc.) flags.
  - Writing lower-level classes, functions, and methods, in order to extend the language.
- A manufacturer has a similar range of choices when choosing the process for making a product. And similarly, many of the choices are made by default.
The "design" (usually?) needs feedback from the process used to make the product. Building too high a wall between "designing" and physically making a physical product is harmful.
- In order to "design" code, a programmer needs feedback. The programmer gets feedback by repeatedly compiling the code, and testing it.
- In order to "design" a thing, a manufacturer needs feedback. The manufacturer gets feedback by making (virtual and/or real) prototypes, and by making production runs. The feedback may go into the design of the current run as a "running change", or the feedback may go into the design of the next version of the product.

I don't think you can compare programming and Manufacturing at all in the AutomaticManufacturing? sense. Think about it, programming is not automatic. Mostly, manufacturing is. The end product is known, the process that lead to it is defined, the tools/machines are in place, it just needs a flick of the wrist to start manufacturing.

What programmer is going to write a piece of code and then repeat that process in mass volume? Or recreate the code by copying it? Senseless, it's not programming.

If you look at manufacturing a single piece of furniture like a CraftsMan? would, then the above issue of designing and getting feedback during manufacturing would take on meaning.

I agree stronger to the GardeningAnalogy? presented in ThePragmaticProgrammer, page 184.

NoelVerhoeven

This appears to be a rather naive view of manufacturing.

In manufacturing, the end product is only partially known; it is up to the users to determine what further refinements are necessary. Individual pieces can always be improved resulting in improvement to the end result. Underlying components change due to changes by suppliers and changes of suppliers. Manufacturing engineers are constantly trying to make the manufacturing process more responsive to change, make it more agile.

The analogy between programming and manufacturing is not inappropriate because of inherent differences in the two, it is inappropriate because few programmers understand manufacturing, hence the analogy does not provide insight to the target audience.

Although there is certainly a strong design element in manufacturing there is a single clear point of differentiation between software development and manufacturing. In manufacturing the whole point of design is to get to the point where things can be repeatedly produced in some quantity, even if only one. In software development the design IS the while point. There is nothing else. In software, it's DesignAllTheWayDown - there is no element of production, no repeated mechanical operation to produce "things". Everything, from the crudest sketches to the lowest level line of code, is a design.

ChrisGerrard

Many, if not most, of the comments on this page are still missing a very fundamental point: TheProgramIsNotTheProduct?. For one thing, unless you work for a software company selling shrink-wrapped software products you aren't ever selling the program. Conventional wisdom says most programmers actually work for internal IT, so it's safe to say most programs are never sold.

So what is the right analogy? TheProgramIsTheAssemblyLine?! So measuring bugs in the program is wrong. Comparing compiling to manufacturing is wrong. What you should be measuring is the output produced by the program. Is your program a website? Measure the number of pages it can produce per unit time, without error. Is it an editor? Measure the number of pages it can spell-check per unit time, and with what accuracy.

When measuring the output of a manufacturing process, you literally don't care what the design looks like, so long as it consistently produces the same output. This is not to say the design doesn't matter. A bad design may be prone to unexpected failure. It may be harder to maintain or have a shorter service life. It may lock you into a service contract with the manufacturer. And coincidentally [ahem] all these factors apply to software.

So yes, programming can be compared to manufacturing. As long as you remember that TheProgramIsNotTheProduct?, TheProgramIsTheAssemblyLine?.

DrewKime

CategoryManufacturing CategoryDiscussion