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
narayanr@pitt.edu
Joseph M. Katz Graduate School of Business
University of Pittsburgh
Pittsburgh, PA, USA
ckemerer@katz.pitt.edu
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.