Product Line Engineering vs. Product-Centric Development
Product Line Engineering (PLE) stands in contrast to classical product-centric development, in which each individual product is developed and evolved independently from other products, or (at best) starts out as a cloned copy of a similar product that is then changed to suit the new product's specific needs.
Product-centric development takes very little advantage of the commonalities among products in a portfolio after the initial clone operation. This is particularly true in a product's sustainment or maintenance phase, where we know that most products consume up to 90% of their project resources.
The illustration shows a stylized view of a production shop in which N products are developed and maintained. In this simplified view, each product comprises requirements, design models, source code, and test cases.
Each engineer in this shop works primarily on a single product. When a new product is launched, its project copies the most similar assets it can find, and starts adapting them to meet the new product's needs. This form of reuse can lead to intractable complexity, especially when we try to make a portfolio-wide change to all of our products. Portfolio-wide changes happen all the time, when we add new features, or comply with new regulations, or fix a recurring defect.
Product-centric approaches impede portfolio production
To illustrate, let's assume that a defect is found in Product B; the defect is traced to an ambiguous or incorrect requirement in Product B's requirements. The Product B team fixes the error, re-designs as necessary, then fixes the code and test cases before re-deploying Product B. Product B is now healthy again.
But suppose that the defect in Product B's requirements was "inherited" when the Product B team copied the requirements from Product A. Suppose further that the source code for Product N was copied from Product B's (defective) source code, and the test cases for Product N were similarly "borrowed" from Product A's (inadequate) test cases.
To really root out the defect from the entire portfolio, each of the N product teams should really confer with each of the other N-1 product teams. These communication paths are shown via red lines in the illustration. This communication obligation imposes an overhead that grows as the square of the number of products.
That means that in a relatively modest product line of 30 products, some 900 inter-project communication paths should be activated.
This complexity will quickly overwhelm any engineering staff; in order to get their products out the door on time and on budget, each product team will focus more on their product silo and less on taking advantage of the commonalities and interdependencies among the other products. The result is divergent product silos, low degrees of sharing, and high duplication of effort across the product silos to fix the same defect multiple times in multiple products, or to independently implement the same enhancements in different ways in different products.
Clearly, product-centric development lacks the ability to scale. Productivity, product quality, or economies of production will degrade as the portfolio grows larger over time.
In organizations where engineering capability is about to be (or has been) swamped by the engineering complexity of their portfolio, missed deadlines, missed market opportunities, decreasing quality, and lower employee morale are the norm.