It Takes Two

It Takes Two
PAUL CLEMENTS

People considering the move to a product line strategy usually get around to asking some form of the question, “So how much is this going to cost us in the short term?” A time-based version of the question is, “How many days/months/years will it take for my up-front investment to be recouped by cost savings?” As you can imagine, it’s a difficult question to answer, because of the enormous variations among organizations, products, and markets. The answer is an unsatisfying “It depends.”

Figure 1: Software Product Line Payoff Point

Figure 1: Software Product Line Payoff Point

But that is only if the questioner insists on an answer given in dollars or days. It so happens that there is a very satisfying way to re-frame the question that normalizes the answer across all of the variables. Figure 1 (adapted from Weiss [1]) illustrates the cost model for product lines versus one-at-a-time systems. Without product lines, the cumulative cost begins at zero and rises steadily. With product lines, the cumulative cost begins with the initial cost of the core assets, and then climbs at a shallower rate as projects are turned out. The point at which the two lines cross (and the one-at-a-time cost curve becomes higher) is the payoff point. That cross-over point can be expressed in terms of the number of systems built. Thus, the question becomes how many systems do we need to field before the savings from reuse pay for the up-front investment in building the core asset base? Surprisingly, the answer to this question does not seem to vary much across organizations, products, or markets. What do you imagine it is? Five or six, maybe? Ten? Well, it turns out for the product line approach to pay off, experts agree that the number of systems you need to build is…

Two. Maybe three.

That’s all. And that’s a very good answer indeed, because it’s hard to imagine a product line without at least two or three family members. This means that, practically speaking, every single product line can be expected to reap cost savings when compared to building and maintaining its constituent products separately. Who says so? Apparently, just about everyone:

In their book Software Product Line Engineering, David Weiss and Robert Lai write that the FAST process of product line engineering produces a payoff after about three systems [1]. Subsequent to the book’s publication, Weiss reports new data from Lucent Technologies software product lines that suggests the payoff point is usually between two and three. Audris Mockus and Harvey Siy confirm this with excellent data that shows that for a FAST-based product line at Lucent called AIM, “the first nine months of applying AIM saved around three times more effort (61/21) than was spent on implementing AIM itself” [2]. (Savings were $6-9,000,000.)
Jacobson et al. report in Software Reuse: Architecture, Process, and Organization for Business Success [3] that a component used three to five times in application projects will recover the initial cost of creating it and the ongoing cost of supporting it. It costs 1.5 to 3.0 times as much to create and support a reusable component as it does to implement a similar component for a single application (suggesting that the payoff point is 1.5 to 3.0 projects). It costs only one quarter as much to utilize a reusable component as it does to develop a new one from scratch. It takes two or three product cycles, they say, before the benefits of reuse become significant.

In Measuring Software Reuse, Jeff Poulin writes that large-scale strategic reuse (the essence of a product family) becomes worthwhile after the assets are used in a total of three applications [4]. Other reuse experts seem to agree. Don Reifer says the cost recovery point is three in Practical Software Reuse [5], as does Will Tracz in Confessions of a Used Program Salesman [6], and Ted Biggerstaff (reported by Tracz in a reuse workshop summary [7]). The data of Jacobson et al., cited above, are completely consistent with this estimate.

John Gaffney and Bob Cruikshank of the Software Productivity Consortium published data in 1992 about SPC’s synthesis method of domain and application engineering. Their data, ranging across three application domains, showed that the payoff point for product-line-style reuse was between 1.67 and 4.86 systems [8]. They also showed that return-on-investment is based on the payoff point: ROI = (N/N0 – 1)100%, where N is the number of systems built and N0 is the payoff point.
A major American aerospace company has told us they believe the payoff point for their product line of avionics systems comes after about two major block upgrades. A block upgrade is a new, substantially-revised version of one of the avionics systems in their family--in essence, a new family member.

The reuse figures would not seem to take into account the overhead of organizational change that is inherent in adopting a product line approach, and so might seem a little low--at least at first glance. But organizations that are aggressive and disciplined about reuse (even if they don’t call what they’re doing a product line) must have worked out responsibilities for building the reusable assets and insuring their reuse in a disciplined way, and so their payoff point reflects the organizational re-structuring necessary to achieve that. So accepting their payoff point at face value will probably not take us too far off the mark. And to reinforce that, the Lucent, SPC, and aerospace examples do take the organizational costs into account, and their payoff points are even a bit lower.

This result is very encouraging. It’s almost a certainty that if you’re planning a product line, you’re planning to have at least three products in it. So a slightly different flavor of our opening question is “Will I save money by adopting a product line approach?” And the answer is a very reassuring “Almost certainly.”

Now we aren’t promising that you’ll make money. People have to actually buy your products for that to happen, and even the most breathtakingly efficient production process can’t guarantee that. Instead, we’re talking about the relative costs of building a set of products as a product line, versus building the same set as unrelated one-of-a-kind products. The point here is that if you’re planning to build three or more related systems – not a particularly burdensome requirement for a product line--then building them from a common set of core assets is almost guaranteed to be the more economical way to turn them out.

References

[1] Weiss, D. M. & Lai, C. T. R. Software Product-Line Engineering: A Family-Based Software Development Process. Reading, MA: Addison-Wesley, 1999.

[2] Mockus, A. & Siy, H. “Measuring Domain Engineering Effects on Software Coding Cost,” 304-311. Proceedings of Metrics 99: Sixth International Symposium on Software Metrics, Boca Raton, FL, November, 1999. New York, NY: IEEE Computer Society Press, 1999.

[3] Jacobson, I.; Griss, M.; & Jonsson, P. Software Reuse: Architecture, Process, and Organization for Business Success. New York, NY: Addison-Wesley, 1997.

[4] Poulin, J. S. Measuring Software Reuse: Principles, Practices, and Economic Models. Reading, MA: Addison-Wesley, 1997.

[5] Reifer, D. J. Practical Software Reuse: Strategies for Introducing Reuse Concepts in Your Organization. New York, NY: John Wiley and Sons, Inc., 1997.

[6] Tracz, W. Confessions of a Used Program Salesman: Institutionalizing Software Reuse. New York, NY: Addison-Wesley, 1995.

[7] Tracz, W. “RMISE Workshop on Software Reuse Meeting Summary,” 41-53. Software Reuse: Emerging Technology. Los Alamitos, CA: IEEE Computer Society Press, 1998.

[8] Gaffney, J. E. & Cruickshank, R. D. “A General Economics Model of Software Reuse,” 327-337. Proceedings of the 14^th ICSE, Melbourne, Australia, May 11-15, 1992. New York, NY: ACM, 1992.

About the Author

Dr. Paul Clements is a senior member of the technical staff at Carnegie Mellon University's Software Engineering Institute, where he has worked for 8 years leading or co-leading projects in software product line engineering and software architecture documentation and analysis.

Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998, second edition due in late 2002), Evaluating Software Architectures: Methods and Case Studies (2001), and Documenting Software Architectures: View and Beyond (2002). He also co-wrote Software Product Lines: Practices and Patterns (2001), and was co-author and editor of Constructing Superior Software (1999).In addition, Clements has also authored dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems.

He received a B.S. in mathematical sciences in 1977 and an M.S. in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a Ph.D. in computer sciences from the University of Texas at Austin in 1994.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.