While manufacturing principles have brought higher-quality products to a wide variety of markets in shorter production times and at reduced costs, the software industry has struggled in applying the lessons of mass assembly to new application development. Manufacturing assembly in the software world requires standard building blocks to work from as the raw materials - in this case, reusable standard software components. That's no easy task, but achievable in the software world. What has held back true industrial production from those raw materials has traditionally been the more challenging processes and methodology required to transform those software components into an assembly that can produce competitive software.

We should keep in mind how long it took for manufacturing to realize the processes, means of capital, and technological innovation that enabled what we now take for granted. Agriculture has been around since the dawn of civilization, but there are still many areas that rely on manual labor. Household goods were produced for thousands of years before division of labor, automated assembly lines, and robotic manufacturing turned them into commodities.

The assembly process is inherently a difficult one. Over 30 years ago Fred Brooks laid out the foundation of software project management in The Mythical Man Month. The basic premise was that each subdivision of the labor required to build a system (or assembly) would increase the total number of communication interfaces (Brooks uses the formula n(n-1)/2) required to manage the project team. Once this premise is accepted, two realities are apparent:

1. Dividing an assembly into smaller chunks actually increases the total amount of work required to complete the assembly.
2. An assembly will necessarily depend on integrating subsystems, so any miscommunication between teams will be realized at assembly time.

These two factors make it unlikely that we will ever see a production line for creating software applications or systems. When breaking down an assembly into sub-assemblies there is no true division of labor. The person or team that builds the sub-assembly will need the same skill set as the person or team that just built the large assembly itself. Additionally given the huge knowledge and productivity gaps between highly-talented developers and average developers, trying to increase throughput by assigning sub-assemblies to inferior developers (or teams of developers) is like adding tomato juice to ketchup to make it thicker.