History of Product Lines

The idea of product lines is not new. Eli Whitney created interchangeable parts for rifles in the 1880s to fill an order for ten thousand muskets for the U.S. government. He did this because only a handful of skilled machinists were available in Connecticut at the time. A few decades later, Henry Ford perfected the assembly line to create Model T cars. Ford's process was instrumental in achieving orders-of-magnitude increases in automobile productivity. He was able to provide a complex product at a relatively inexpensive price to the American public through increases in productivity.

The Manufacturing Metaphor

Before dropping everything and setting up an assembly line 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 its 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.

In software, no universally accepted quantitative measurement states that a component that has four interfaces is better than one that has two interfaces. In software, it is often said that source code modules "should not be more than 1,000 lines of code" and the design should exhibit "loose coupling" or "high cohesion." Does this mean that a source code file that is over 1,000 lines is a bad one? While we know that a car with one tire will fall over, we cannot say that a source code module with more than 1,000 lines is always a bad one.

Software process and design are less quantitative (measurable with statistics) and more qualitative (measurable with descriptions). Qualitative analysis requires analysis and judgment based on contrasting and interpreting meaningful observable patterns or themes. Several key differences are notable when it comes to the process of manufacturing a product versus creating a software product:

1. Software development is much less predictable than manufacturing a physical 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.

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.