Programming Aint Manufacturing

The analogy between programming and manufacturing is highly flawed, and perhaps serves as the foundation of a number of counterproductive organizational ideas in technology companies.

Manufacturing is the act of carrying out a repeatable process. The elements required to put this process into action -- human labor, capital investment -- are relatively expensive.

Programming is the act of defining a repeatable process. Once you have the process, the required elements -- CPUs, RAM -- are extremely inexpensive by comparison.

You can see companies applying a programming-manufacturing analogy whenever they do any of the following:

Farm out the programming labor to wherever it's cheapest.
Split a big programming job up into a bunch of small parts, misunderstanding the opportunity for lateral efficiency in software. Often, the person who manages the delegation is called a SystemArchitect.
Maintain a massive army of underskilled coders who are ready to be unleashed on your big project. This helps your sales pitch; you can bring the big corporate client into your office and tell him "We could have 40 Java coders on your project next week!"

There are a lot of clients who don't understand software, so it's not hard to sell them with these techniques. The result is almost always that quality suffers.

Discussion:

These are classic mistakes in both programming and manufacturing. Granted, many successful manufacturers "farm out the labor" to cheap locations. But they usually need to rethink the design to take advantage of the cheaper labor and materials. And there are huge opportunities for "lateral efficiency" in manufacturing. These opportunities are best realized by thoughtful engineers, technicians, machinists, assemblers, managers, salespeople, and other personnel.

Perhaps the topic sentence should be changed to:

The AnalogyBetweenProgrammingAndManufacturing has flaws. (One of the flaws is that most people don't realize how much design/programming is a part of manufacturing.) The analogy is the foundation of a number of counterproductive organizational ideas in technology companies.

or even:

The AnalogyBetweenProgrammingAndManufacturing has flaws. (The biggest flaw is that people don't know how much design/programming is a part of manufacturing.) The analogy is the foundation of a number of counterproductive organizational ideas in technology companies.

As the person who started this page, my intent was to provide a very direct counterargument to a lot of what goes on in a page such as AnalogyBetweenProgrammingAndManufacturing. I want to state in the most direct terms possible why I think such an analogy is really quite wrong, and I wanted there to be a focal point for others who might have arguments in the same vein. (Of course, just because you start a Wiki page doesn't mean you own it, but that was my intent.)

So if the topic sentence comes across as being quite strong, it was intended that way. It's meant to be at least a little provocative.

This has been discussed before on the wiki, see TheSourceCodeIsTheDesign.

The biggest problem with the analogy between manufacturing and programming is the lack of people who understand both. Using manufacturing as an analogy for people who don't understand manufacturing is kind of pointless and does not help anyone.

I manage the NightlyBuilds? for an agile development team, and I've consulted on build-and-release for years. The way I describe it to clients is that:

Your build machines/scripts/tools are your factory and your test facility
Your factory is so efficient and flexible that it can knock out a new model in minutes and start testing it automatically and immediately.
I'm your foreman
Your dev team are your designers
Let me worry about building your stuff. Let them worry about designing something worth building. You worry about speccing out a product worth designing.

--RobMandeville

CategorySoftwareProduct