Towards a Model for Optimizing Technical Debt in Software Products Narayan Ramasubbu

Chris F. Kemerer

Joseph M. Katz Graduate School of Business University of Pittsburgh Pittsburgh, PA, USA [email protected]

Joseph M. Katz Graduate School of Business University of Pittsburgh Pittsburgh, PA, USA [email protected]

Abstract— There is a growing interest in applying the technical debt metaphor to investigate issues related to the tradeoff of the likely long-term costs associated with software design shortcuts for expected short-term business benefits in terms of increased earlier functionality. We propose an optimization model that contrasts the patterns of technical debt accumulation in a software product with the patterns of consumer adoption of the product throughout its evolution. This facilitates a rigorous and balanced analysis of the pros and cons of accumulating technical debt at various lifecycle stages of a software product. We discuss the use of the optimization model to derive policies for managing technical debt and the potential for empirical tests of the model and other future interdisciplinary research. Index Terms—technical debt, software platforms, customer satisfaction, customization, software quality, customer adoption.

I. INTRODUCTION Managing resource allocation to competing needs in enterprise software product development has been acknowledged as a challenging problem [1, 2, 3, 4]. Often, product developers face situations where they will have to trade off potential longer-term benefits for immediate short-term returns. For example, a product development team with limited resources and facing an aggressive business deadline might compromise on the modularity of the product design in order to introduce new features that the marketing team believes are crucial to gaining competitive advantage [see examples in 1, 3]. Such a compromise to software product design has been termed technical debt. Similar to financial debt, software developers incurring technical debt face the obligation to pay back the principal along with interest as their product evolves. We observe four interrelated research streams in the emerging literature on technical debt: (a) taxonomy, frameworks, and perspectives on technical debt [1, 2, 3, 4, 5, 6, 7, 8, 9]; (b) identifying, measuring, and visualizing technical debt [9, 10, 11, 12, 13, 14]; (c) measuring and assessing the impact of technical debt on project and firm performance [6, 15, 16, 17, 18, 19, 20, 21, 22, 23]; and (d) decision frameworks for managing technical debt [3, 24, 25, 26, 27, 28, 29]. Moving beyond the metaphorical conceptualization of technical debt, these four streams of research collectively pave a way to develop rigorous empirical models that could be used to derive appropriate policies for managing technical debt.

Current empirical models of technical debt have focused on providing strong empirical evidence for the negative impacts of technical debt on performance [6, 15, 16, 17, 18, 19, 20, 21, 22, 23], which has aided the development of decision frameworks that help managers to monitor and avoid excessive buildup of technical debt [3, 24, 25, 26, 27, 28, 29]. However, prevailing models do not fully consider the underlying optimization problem, namely, the tradeoffs between the costs of the debt and the benefits derived from incurring technical debt. While such tradeoffs have been qualitatively discussed [2, 3], building rigorous empirical models has remained a challenge. One key obstacle is to model the evolutionary nature of the technical debt accumulation, accounting for the interplay between the benefits and costs of technical debt over the lifecycle of a software product. A cross-sectional analysis of the relationship between technical debt and performance would provide a limited view, failing to account for the evolutionary way in which the benefits and costs associated with technical debt accrue and interact with each other. In this research we address this gap in the literature by developing an optimization model that allows researchers to trace the different pathways of a software product evolution contingent on the way technical debt is managed. We anchor our optimization model in the empirically-validated patterns of customer adoption and diffusion of products in the management literature [30, 31], and use it to compare the different patterns of accumulation of technical debt. This research has the longer term goal of developing a common ground for further interdisciplinary research by illuminating the linkages between the technical debt optimization problem and broader issues, such as adoption and diffusion considered in the product management and technology management fields. The rest of the paper is organized as follows: In the next section we describe an enterprise software product development environment which we use as a relevant research context to develop and illustrate our optimization model. Following this, we present the basic mechanisms of our optimization model that illustrate the evolutionary trajectories of both high and low technical debt product growth. In section III we discuss the future steps towards empirical validation of our optimization model.

II. CONCEPTUAL DEVELOPMENT A. Platform-Based Enterprise Software Context As technical debt is a longitudinal, life-cycle issue in the evolution of software [32], we motivate our optimization models in a relevant real-world context. We adopt the case of platform-based enterprise software products, where a platform sponsor produces a mass-customized product that customers use as a base from which to further tailor their individual implementations. Platform-based product development is typical in a majority of enterprise software applications such as Enterprise Resource Planning, Customer Relationship Management, Human Capital Management, and Supply Chain Management Systems, garnering a worldwide market of more than 120 billion USD in 2012 [33]. The base product (or platform) can be altered in a variety of ways (i.e., customized) to suit the specific context of a client. For example, an aggressively growth-oriented business could demand features at a faster pace than the platform-sponsor could fulfill using standard releases. Software personnel at such a client site typically respond by customizing the product in order to add the new requested features that go beyond the standard functionality of the base platform product. In contrast, a different customer may not utilize all the features offered by the base platform product, or may not wish to incur the risk of customization, and may not modify the product in any way. Thus, depending on the extent of customization and utilization, the evolution of a tailored product at a client site could be significantly different from the base platform over the lifecycle of the product. Such variations in product growth trajectories at client sites provide an excellent research context to investigate a suitable optimization model for managing technical debt. B. Customer Adoption and Diffusion Pattern In order to derive an optimization model for analyzing technical debt we conceptualize the growth trajectories of a base platform product and its product variants in the following way. Drawing from marketing and product management research [30], we posit that the optimal rate of growth of functionality in a software product would match the rate of customer adoption of the features by customers. Research in marketing on the patterns of customer adoption of a wide variety of goods has been shown to follow an “S”- shaped curve with distinct takeoff and saturation points [30]. In Figure 1, which shows the relationship of cumulative functionality over time, the base platform curve (solid dark line) shows such a pattern; point a in the curve (corresponding to time t1) shows the point at which the customer adoption of the product “takes off” after a slow initial growth; point b in the curve (corresponding to time t2) shows the point at which the customer adoption of the product begins to wane. We expect that the rate of functionality growth in the base platform to follow the above-mentioned “S” curve. Formally, such a pattern could be modeled using a logistic growth curve defined by F = K / 1 + e –(a+bt), where F is the functionality added to the base platform, K is the maximum equilibrium value of the functionality, t is the time variable, b is the rate of

functionality growth coefficient, and a is a constant used to position the curve on the time scale. C. High and Low Technical Debt Trajectory In an aggressive growth scenario, business demands from early adopters force software personnel to quickly add functionality to the product, which results in an initial higher rate of functionality growth than the base product, but also an increased amount of technical debt. Thus, the takeoff point of the high technical debt product variant occurs much earlier than in that of the base platform. However, such an increased rate of growth in functionality cannot continue indefinitely because the induced complexity (the technical debt) of the shortcuts taken by the software personnel in order to quickly release features is likely to catch up with them, significantly hindering future product development and maintenance [3, 34]. Thus, the growth trajectory of a high technical debt product variant would also depict a saturation point that occurs earlier in the lifecycle than that of the optimal growth of the base platform. As shown in Figure 1, we model the high technical debt growth trajectory (dotted line) using an exponential saturation curve, which can be modeled as F= K (1-e-bt). In contrast to the high-debt variant, in a business context where the product starts with a low utilization scenario, the takeoff point of the product’s growth is delayed. That is, customers install only a subset of modules of the base-platform to fit their need. Another reason for the low utilization of base platform modules could be an excessive focus on reliability and quality considerations. That is, software personnel actively shun any modules of the platform that have not been thoroughly tested or those that do not meet the quality standards of the organization. Thus, the low-debt product variant can be conceived as a relatively higher quality variant (due to, inter alia, the absence of shortcuts and the simpler product structure). Because of the lower complexity and higher quality embodied in the low-debt product variant, its performance does not saturate early, facilitating a longer “shelf life” than the high-debt variants and even the base platform. Conceptually, the growth trajectory of the low-debt product variant can be seen as diametrically opposite to that of the high-debt variant, and is modeled in Figure 1 (dashed line) using the exponential growth function F= ebt. D. Optimization and Managerial Decisions The models of the growth trajectories of the three product variants shown in Figure 1 provide a decision framework to assess the overall benefit (or loss) of incurring technical debt at any point in the lifecycle of the products. For example, the overall benefits of incurring technical debt and accelerating product growth beyond the base platform can be calculated using the area between the high-debt exponential saturation curve and the base-platform “S” curve before they intersect, as shown in Figure 1. If the value of benefits due to the increased functionality in the high-debt product variant outweigh the loss due to early performance saturation (i.e., the area between the high-debt and base platform curve after they intersect), then incurring the high debt is worthwhile, ceteris paribus. Thus, the business value of a high-debt strategy can be derived

as shown in Equation 1, where R is the retirement time of the product. The retirement time of a software product that has been customized by a client can vary from that of its base product platform depending on several factors including the client’s specific IT planning horizon and business needs. The value of the low-debt strategy is the net of the losses due to lack of functionality in the early stages of the product lifecycle and the performance gains of the low-debt product variant during the last stage of the product lifecycle (after the intersection point of the low-debt and base platform curves). This net business value can be derived using the area between the low-debt curve and the base platform curves shown in Figure 1, and is presented in Equation 2. Business value of high-debt strategy

=

∫ (t=0,R) [(value of increased functionality) – (loss due to early performance saturation)] dt. 

Business value of low-debt strategy

=

∫ (t=0,R) [(value of performance gains towards end of product life) – (loss due to lack of early life functionality)] dt

It is important to note that in contrast to existing models, in our conceptualization the value or loss of incurring technical debt depends on the retirement time frame (t=R) of the product as well as the business value derived from the cumulative features facilitated by the product growth while it is in use. Thus, our formulation avoids one-sided or conservative policies based on premeditated notions such as “incurring technical debt is bad” or “avoiding debt is good” [12]. Instead, the value of incurring or avoiding technical debt need to be carefully considered in relation to the planned shelf life of the product, opportunities from new technological innovations, and the ability to derive business benefits from the product features. An additional benefit of our conceptualization is that it can easily accommodate cost of quality considerations by accounting for the gains due to improved reliability (low-debt variant) or losses due to poor reliability (high-debt variant) [35]. In addition, these models allow us to highlight six key decision points throughout the product evolution – three on the

high-debt trajectory (HD1-3) and three on the low-debt trajectory (LD1-3). Referring to Figure 1, the first points on the high debt and low debt curves (HD1 and LD1, respectively) pertain to fruitful opportunities for product managers to alter their existing product growth trajectories before the general takeoff of the product in the marketplace (before t1 or the point a on the base platform curve). Since the product has not widely taken off in the market, managers could treat their debt-taking or debt-avoiding strategies as early experiments only, and account any associated costs as learning investments. Altering the product growth trajectories at HD1 and LD1 would be relatively easier as these occur in the early phase of the product lifecycle when the code base is relatively smaller. Once a product takes off (after t1 or point a), platform sponsors typically provide product road maps and details about anticipated release of future product features, which could be utilized for calculating potential debt-obligations of high-debt product variants and the losses due to lack of functionality in low-debt product variants. Thus, HD2 is a good point to get a reliable estimate of the extent of the debt obligation of the high-debt variant that needs to be paid off in the future. Similarly, for the low-debt product variant, LD2 is a decision point where a product manager could reliably estimate the opportunity costs of missed functionality and determine whether to alter growth paths. HD3 is the end stage of value creation due to high technical debt. It occurs when the performance of the high-debt variant begins to saturate (flattening of the curve). If the product is retired at this point (say, for example, substituted by a new technology), the potential debt obligation could be written off and the firm would have accrued a positive value due to its aggressive strategy. However, if the firm is not able to retire the product at this stage, it faces a debt obligation as described in the literature. Similarly, LD3 is the end stage decision point on the low-debt curve, which presents an opportunity for the firm to recover lost value due to lack of functionality. If the firm could rapidly ramp-up its development at this stage, it would be able to reap significant benefits due to increased performance of its products at a relatively cheaper cost as compared to the high-debt and base platforms.

Fig. 1. Cumulative Functionality Vs. Time: Product Growth Trajectories

III. VALIDATION AND FUTURE WORK We are currently working on validating the empirical models conceptualized in this paper using field data collected from a large European enterprise software product development firm. We have collected data pertaining to multiple years of evolution of the firm’s customer relationship management software product and the product’s implementation at tens of large customers. We are currently performing statistical analysis of the data and expect to be able to present some preliminary results at the workshop. REFERENCES [1] W. Cunningham, “The Wycash Portfolio Management System,” in Proceedings of Object-Oriented Programming Systems, Languages, and Applications, Vancouver, 1993, pp. 29-30. [2] N. Brown, Y. Cai, Y. Guo, et al., “Managing Technical Debt in Software-Reliant Systems,” in Proceedings of FSE/SDP Workshop on Future of Software Engineering Research, Santa Fe, New Mexico, USA, 2010, pp. 47-52. [3] J. Woodard, N. Ramasubbu, T. Tschang, and V. Sambamurthy, “Design Capital and Design Moves: The Logic of Digital Business Strategy,” MIS Quarterly, forthcoming, 2013. [4] M. Fowler. "Technical Debt," accessed on January 18, 2013; http://martinfowler.com/bliki/TechnicalDebt.html. [5] C. Izurieta, A. Vetro, N. Zazworka, Y. Cai, C. Seaman, and F. Shull, “Organizing the Technical Debt Landscape,” in 3rd Int. Workshop on Managing Technical Debt, Zurich, 2012. [6] N. Ernst, “Technical Debt and Requirements,” in 3rd Int. Workshop on Managing Technical Debt, Zurich, 2012. [7] T. Theodoropoulos, M. Hofberg, and D. Kern, “Technical Debt from the Stakeholder Perspective,” in 2nd Int. Workshop on Managing Technical Debt, Waikiki, Hawaii, USA, 2011. [8] T. Klinger, P. Tarr, P. Wagstrom, and C. Williams, “An Enterprise Perspective on Technical Debt,” in 2nd Int. Workshop on Managing Technical Debt, Waikiki, Hawaii, USA, 2011. [9] C. Baldwin, and A. MacCormack, "Finding Technical Debt in Platform and Network Architectures," at The Mathworks, 2011. [10] R. Gomes, C. Siebra, G. Tonin, et al., “An Extraction Method to Collect Data on Defects and Effort Evolution in a Constantly Modified System,” in 2nd Int. Workshop on Managing Technical Debt, Waikiki, Honolulu, HI, USA, 2011. [11] C. Seaman, and Y. Guo, "Measuring and Monitoring Technical Debt," Advances in Computers, M. V. Zelkowitz, ed., pp. 25-46, London, UK: Academic Press, 2011. [12] B. Boehm, “Assessing and Avoiding Technical Debt,” in 3rd Int. Workshop on Managing Technical Debt, Zurich, 2012. [13] J. Brondum, and L. Zhu, “Visualising Architectural Dependencies,” in 3rd Int. Workshop on Managing Technical Debt, Zurich, Switzerland, 2012. [14] J. D. Morgenthaler, M. Gridnev, R. Sauciuc, and S. Bhansali, “Searching for Build Debt,” in 3rd Int. Workshop on Managing Technical Debt, Zurich, Switzerland, 2012. [15] J. Bohnet, and J. Döllner, “Monitoring Code Quality and Development Activity by Software Maps,” in 2nd Int. Workshop on Managing Technical Debt, Waikiki, HI, USA, 2011. [16] N. Brown, R. L. Nord, I. Ozkaya, and P. Kruchten, “Quantifying the Value of Architecting within Agile Software Development

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33] [34] [35]

via Technical Debt Analysis,” in 2nd Int. Workshop on Managing Technical Debt, Waikiki, Honolulu, HI, USA, 2011. J. Heintz, and I. Gat, “Investigating From Assessment to Reduction: Reining in Millions,” in 2nd Int. Workshop on Managing Technical Debt, Waikiki, Honolulu, USA, 2011. A. Nugroho, J. Visser, and T. Kuipers, “An Empirical Model of Technical Debt and Interest,” in 2nd Int. Workshop on Managing Technical Debt, Waikiki, HI, USA, 2011. N. Zazworka, C. Seaman, F. Shull, and M. Shaw, “Investigating the Impact of Design Debt on Software Quality,” in 2nd Int. Workshop on Managing Technical Debt, Waikiki, 2011. B. Curtis, J. Sappidi, and A. Szynkarski, “Estimating the Principal of Technical Debt,” in 3rd Int. Workshop on Managing Technical Debt, Zurich, Switzerland, 2012. F. A. Fontana, V. Ferme, and S. Spinelli, “Investigating the Impact of Code Smells Debt on Quality Code Evaluation,” in 3rd Int. Workshop on Managing Technical Debt, 2012. J. d. Groot, A. Nugroho, T. Back, and J. Visser, “What is the value of your Software?,” in 3rd Int. Workshop on Managing Technical Debt, Zurich, Switzerland, 2012. J. D. McGregor, J. Y. Monteith, and J. Zhang, “Technical Debt Aggregation in Ecosystems,” in 3rd Int. Workshop on Managing Technical Debt, Zurich, Switzerland, 2012. W. Snipes, and B. Robinson, “Defining the Decision Factors for Managing Defects: A Technical Debt Perspective,” in 3rd Int. Workshop on Managing Technical Debt, Zurich, 2012. C. Seaman, Y. Guo, C. Izurieta, Y. Cai, N. Zazworka, F. Shull, and A. Vetro, “Using Technical Debt Data in Decision Making: Potential Decision Approaches,” in 3rd Int. Workshop on Managing Technical Debt, Zurich, Switzerland, 2012. J.-L. Letouzey, “The SQUALE Method for Managing Technical Debt,” in 3rd Int. Workshop on Managing Technical Debt, Zurich, Switzerland, 2012. N. Zazworka, C. Seaman, F. Shull, and M. Shaw, “Prioritizing Design Debt Investment Opportunities,” in 2nd International Workshop on Managing Technical Debt, Waikiki, HI, 2011. W. Nichols, “A Cost Model and Tool to Support Quality Economic Trade-off Decisions,” in 2nd Int. Workshop on Managing Technical Debt, Waikiki, Honolulu, USA, 2011. Y. Guo, and C. Seaman, “A Portfolio Approach to Technical Debt Management,” in 2nd Int. Workshop on Managing Technical Debt, Waikiki, HI, USA, 2011. V. Mahajan, E. Nullier, and F. M. Bass, “Diffusion of New Products: Empirical Generalizations and Managerial Uses,” Marketing Science, 14 (3), pp. G79-G88, 1995. R. G. Fichman, and C. F. Kemerer, “The Illusory Diffusion of Innovations: An Examination of Assimilation Gaps,” Information Systems Research, 10 (3), pp. 255-275, 1999. C. F. Kemerer, and S. Slaughter, “An Empirical Approach to Studying Software Evolution,” IEEE Transactions on Software Engineering, 25 (4), pp. 493-509, 1999. Gartner. "Enterprise Software Markets, Worldwide 2011-2016, 2Q12 Update,” Report ID number: G00230946. C. Baldwin, and K. B. Clark, Design Rules Vol. 1: The Power of Modularity, Cambridge, MA: The MIT Press, 2000. S. Slaughter, D. E. Harter, and M. S. Krishnan, “Evaluating the Cost of Software Quality,” Communications of the ACM, 41(8), pp. 67-73, 1998.