7 Steps to Pay Down the Interest on Your IT Technical Debt

Contents

I. Introduction 1 IV. The Real World of Technical Debt 15
Case Study: Large insurer 16
Case Study: Telco provider 18
II. Measuring Technical Debt 3
V. Conclusion 20

III. The 7-Step Technical Debt 7
Management Cycle VI. About CAST 21

7 Steps to Pay Down the Interest on Your IT Technical Debt

I: Introduction

We all make mistakes.
That point could not have been clearer in 2011, a year in which experts generally Whatever the cause of
believe that more IT system failures, outages and data breaches occurred than any
previous year since the dawn of the age of technology. And while some of these application software failure,
issues could be traced to intentional and malicious undermining of systems, many, the cost of fixing the
if not most, had some measure of application software failure or weakness at
their root. resulting structural quality
problems in production code
These failures or weaknesses in application software stem from two areas. One is
when developers write software that violates good architectural or coding practices to control development costs
causing structural flaws in the code. The other is found in legacy code – lines of
or avoid operational
code that are carried over from previous versions of application software – which
either do not work properly with the new code being written, are no longer valid or problems is called
carry defects that were not previously detected, thereby exposing the new software
Technical Debt.
to failure or breach.

1 7 Steps to Pay Down the Interest on Your IT Technical Debt

Introduction

As depicted in Figure 1, the causes of Technical Debt vary from simple Technical Debt Inelegant code
explanations like an inadvertent coding mistake to intentional shortcuts based ‘priority fix’ ‘fix not required’

on business needs. Regardless of the origin, organizations that do not address
the resulting structural flaws before application software is deployed expose
Intentional
themselves to significant risk and will inevitably find themselves addressing Prioritized Fix if
coding
refactoring time allows
the issues when they manifest themselves as application failures. This is how shortcut

Technical Debt is amassed.

Inadvertent Prioritized Learning
Left unaddressed, Technical Debt can so degrade an mistake bug fixing opportunity

application that its benefits to the business cannot be
justified by its growing costs or operational risks. Figure 1. Reasons for Technical Debt

Consequently, managing Technical Debt is an executive
liability for those responsible for governing the costs
and risks of application portfolios.


II: Measuring Technical Debt

Although Technical Debt represents liability, it
also represents a way to apply financial terms to
the business risks associated with operational “Technical Debt’s usefulness

performance of critical business applications. has been limited historically
because most organizations
Technical Debt’s usefulness has been limited historically because most have not known how to
organizations have not known how to measure it. As a result, these
organizations have been incapable of using Technical Debt to estimate
measure it.”
the costs of application ownership or to guide management decisions
about how much to invest in application quality, which, when left
unfunded, leads to more Technical Debt being accrued.


Measuring Technical Debt

Recent advances in software analysis and measurement, however,
have solved this problem. Automated analysis and measurement is far Hours to
correct Historical data
more accurate than previously employed manual assessments and is problems on maintenance

therefore more reliable and efficient at detecting software quality issues
– meaning companies now have an objective measurement of an Technical
Structural
quality Static analysis
Debt problems of applications
application’s Technical Debt, making it a critical and effective tool for
application management.
Developers
burdened IT or contractor
hourly rate finance records
Still, a single method of measuring Technical Debt does not exist.
Generally speaking, Technical Debt can be calculated by analyzing the
structural quality of an application, rating the severity of each problem, Figure 2. Components and Data Sources
and identifying the “must-fix” problems. Using this roadmap, CAST has to Calculate Technical Debt

worked extensively with industry leaders to research and devise a
method for calculating Technical Debt, as shown in Figure 2, based on
the number of must-fix problems in the code, the time needed to “...companies now have an objective
correct the problems and the cost to fix the problems.
measurement of an application’s
Technical Debt, making it a critical
and effective tool for application
management.”



Number of must-fix problems: The first step in calculating
Technical Debt is to determine which issues will be addressed. ((.1 LSV + .25 MSV + .5 HSV) x 1 hour x $75)
Based on its research, CAST assumes that only 50% of high Where, LSV = Low Severity Defects
MSV = Medium Severity Defects
severity problems, 25% of moderate severity problems, and
HSV = High Severity Defects
10% of low severity problems will ultimately be corrected in
the normal course of operating the application.
Figure 3. CAST’s Formula for Calculating Technical Debt

Time to correct problems: The next element in the calculation is the
time it takes for remediation. The time to fix a structural quality problem includes
the time to analyze the problem, understand the code and determine a correction,
evaluate potential side-effects, implement and test the correction, and release the Using each of these
correction into operations.
elements, the formula
Cost to fix problems: The final element in calculating Technical Debt is the cost of developed by CAST to
the time spent by a developer to remediate the issues. CAST found that the data on
calculate Technical Debt
this subject varies widely from company to company, but based on its research it
determined that $75 per hour was a conservative estimate of the average rate for is depicted in Figure 3.
developers. This figure, however, should be treated like a variable rather than a
constant and companies calculating their own Technical Debt should use whatever
the average rate for their developers is.



It is important to note that the Technical Debt formula presented only provides a basis
“CAST employed the formula
for benchmarking. Organizations can and should adjust the parameters in the formula
to fit their own maintenance and structural quality objectives, experiences and costs. on the previous page in its
2011-2012 CRASH Report,
CAST employed the formula on the previous page in its 2011-2012 CRASH Report
(CAST Report on Application Software Health), based on analysis of 745 applications based on analysis of 745
containing 365 million lines of code (11.3 million backfired function points) submitted
applications containing 365
between 2008 and 2011 by 160 organizations located primarily in the United States,
Europe and India. million lines of code.”

In doing so, it determined that the
average Technical Debt accrued per line
of code (LOC) for all applications
reviewed was $3.61. That means even a
slightly below average sized application
containing 300,000 LOC carries more
than $1 million in Technical Debt.


III: The 7-Step Technical Debt Management Cycle

Just as individuals make decisions on how to pay The Technical Debt Management Cycle is a seven-step
process for analyzing and measuring Technical Debt
down personal debt, organizations need to (presented in Figure 4), that relies on comparing it to both

determine how they will retire Technical Debt. IT and business priorities. This process begins by
translating executive business priorities into Technical
Debt targets for each application.
Trying to do this on a global level can be
overwhelming and it is often difficult to visualize the
expected payoff. However, the analysis and
Application QA/Build/
measurement of Technical Debt can guide critical IT Executives Managers Developers Release

management decisions about how to allocate
Step 1 Step 2 Step 3
resources for reducing business risk and IT costs. Set strategic Set reduction Measure
quality priorites targets & plans Technical Debt
Executives can set specific reduction targets based
on the strategic quality priorities of their organizations,
Step 4
weighing the costs of remediation against the Plan actions for
remediation
expectation of achieved benefits. This is what is
known as the Technical Debt Management Cycle.
Step 7 Step 6 Step 5
Report to the Remediate
Track results
business violations
It is vital that actions for achieving these targets are
determined in advance, and to track the progress at
each release and periodically report this progress to Figure 4. Flow of the Technical Debt Management Cycle
the business.


The 7-Step Technical Debt Management Cycle

1
Set strategic quality priorities
Since application budgets and time are constrained, IT executives must
“In highly competitive
determine the most critical structural quality objectives each application
service offers to the business and provide clear-cut guidance to application markets, business agility may
managers. In many cases, they will need to set these priorities in concert
be the most critical issue so
with the application managers since executives will generally lean toward business
risk factors, and because structural quality priorities typically vary depending upon Changeability would be a
the purpose of the application software. For instance, in highly regulated industries
priority because of its impact
the most critical issue may be protecting customer data, which would make Security
the highest priority. In highly competitive markets, business agility may be the most on the speed of delivering
critical issue so Changeability would be a priority because of its impact on the speed
new functionality.”
of delivering new functionality. And an online retail application may need to satisfy
several priorities, such as Robustness and Security.

Applications with large and growing levels of Technical Debt related to IT costs may
need to prioritize these factors over business risk issues since the application
architecture can degrade to the point that it becomes unable to serve its business
mission. In these situations, IT executives must determine the balance between
business risk factors and their own internal IT cost factors. Fortunately, structural
quality analysis and measurement provides the data needed to optimize the balance
among strategic priorities.



2
Measure Technical Debt
In much the same way that developers use freeware static analysis
“...the most effective times
tools to measure Technical Debt as part of their unit testing regimen
before submitting code to a build, structural quality flaws that cause to measure structural quality
Technical Debt should also be measured at numerous points in the
are either after each phase of
software life cycle. The difference between the two, however, is that analysis at the
testing level cannot detect serious architectural flaws that may span multiple layers of a build or immediately
the application and may be written in different, sometimes incompatible languages.
before release in order to
These multi-component flaws are often the most devastating during operations and
are the most time-consuming to fix. Consequently, the most effective times to determine the efficacy of the
measure structural quality are either after each phase of a build or immediately before
application as a whole.”
release in order to determine the efficacy of the application as a whole.

The build team or quality assurance typically performs structural quality analysis of
application software, although organizations may conduct it in an Application
Intelligence (AI) Center dedicated to this function. Whoever carries out the analysis
should feed the results back to the development team along with a list of the
violations that yielded the measures. These analyses should be retained as a baseline
to assess progress toward strategic structural quality priorities.



3
Establish reduction targets and plans
To establish a basis for decision-making, application managers need
“...Technical Debt reduction
to translate structural quality priorities into specific targets for their
application. They can accomplish this in a few ways including stating needs to be treated as a
them as thresholds, such as “no high severity performance defects in
standard component of
the operational code base,” or “sustain Transferability scores at or above 2.8
across releases.” The strategic priorities passed down by executive management maintenance or sprint
should provide the guidance needed to allocate resources toward the most critical
planning.
targets.

That, however, is where the tension arises. With every release, there is a “tug-of-war”
over the needs of the organization to provide new functionality quickly to the business
and the need to reduce Technical Debt in priority areas. As a result, structural quality
targets can rarely be achieved in the span of one or two releases. Instead, Technical
Debt reduction needs to be treated as a standard component of maintenance or sprint
planning. Application managers must allocate time for structural quality improvement
into their application maintenance plans, or in an agile environment allocate a
percentage of stories in each sprint to remediating structural quality problems (a
determination that needs to be factored in as part of the design of the agile process).
Since developers frequently participate in these planning activities, they should be aware
of the strategic structural quality priorities against which they are expected to plan.



4
Plan remediation actions
At the beginning of each release planning cycle or sprint, the
“To ensure the process of
application manager and development team can use the structural
quality analysis from the previous release to prioritize a list of reducing Technical Debt
violations for remediation that will help achieve the application’s
remains consistent from one
structural quality targets. The team should select as many high-priority violations to
remediate as can be addressed by the resources allocated during the cycle or sprint, phase to the next, the list of
and it is important to make sure Technical Debt does not increase because of
prioritized violations should
development activities that are separate from those being conducted for the
remediation of Technical Debt. be revised and updated after
each release.”
To ensure the process of reducing Technical Debt remains consistent from one phase
to the next, the list of prioritized violations should be revised and updated after each
release. The rate of progress in remediating the backlog of violations should also be
compared to executive priorities and timelines to determine if the amount of
resources devoted to remediation needs to be adjusted in future cycles or sprints.
This will ensure that Technical Debt planning continues throughout the application
lifespan as part of the longer strategic plan.



5
Remediate violations
Development teams should addresses violations tagged for “If a specific type of flaw
remediation within the cycle or sprint as part of their normal
development or maintenance activities. These remediation activities has been detected numerous
may involve refactoring poorly designed code or correcting specific
times across the code base,
coding weaknesses. Testing and static analysis should then be used to
verify that the flaw has been successfully remediated. The team should keep track of the development team
the time required to remediate structural flaws to help with more accurate estimates
should, as time allows,
on the number of remediation tasks that can be undertaken in future cycles or sprints.
identify the root cause of
If a specific type of flaw has been detected numerous times across the code base,
the flaw and take steps to
the development team should, as time allows, identify the root cause of the flaw and
take steps to eliminate it; with agile in particular, this is an appropriate topic for eliminate it...”
retrospectives at the end of a sprint. Results of these root cause analyses should be
reported back to central team conducting the structural quality analyses so they can
detect trends across the organization.



6
Track results
The application manager should track the ongoing results of “Technical Debt data can be
Technical Debt remediation efforts, compare the results against
established targets and share them with the development team. used as input for estimating
Significant deviations against expected progress should be
and tracking the long-term
addressed when planning upcoming cycles or sprints to develop
achievable commitments based on the resources allocated. cost of ownership for the
application...”
Periodically the application manager and IT executives should review their progress in
retiring Technical Debt and reaffirm application targets against the strategic structural
quality priorities; this allows them to adjust the targets if strategic priorities have
changed. Technical Debt data can be used as input for estimating and tracking the
long-term cost of ownership for the application, while structural quality data needed
for upcoming management decisions regarding the application should be discussed.



7
Report to the business
Following review with the application managers, IT executives should “The discussion of Technical
report the status of Technical Debt to the business. Because it highlights
a direct relationship between aspects of either business risk or IT cost, Debt and its potential
Technical Debt can be translated into terms easily understood by those on
liabilities initiates a dialogue
the business side. Terms like reductions in risk, limiting exposure to security
breaches or outages, increased capability for business agility or reductions in IT’s that provides businesses with
long-term costs all can be illustrated by Technical Debt and resonate with the
greater understanding of the
business side. This information can also be reported to corporate auditors
responsible for assessing risks to the business. IT risks and costs and how
they relate to business issues.”
Translating Technical Debt into business risks, however, requires the business to
articulate its costs and the losses experienced when applications suffer outages,
performance degradation, security breaches, data corruption and similar events. The
discussion of Technical Debt and its potential liabilities initiates a dialogue that
provides businesses with greater understanding of the IT risks and costs and how
they relate to business issues. Consequently, the Technical Debt Management Cycle
provides a vehicle for greater alignment between the business and IT.


IV: The Real World of Technical Debt

While it is one thing to discuss Technical Debt, how
to measure it and how to manage it, it is another
thing all together to put it to use in actual practice.

The following are two cases where the determination of
Technical Debt was used to improve not only the structural
quality of application software, but also the conduct of business.


The Real World of Technical Debt

Case Study
Large insurer cuts maintenance costs 20%
12

A large insurer had a claims management system
10
with 700,000 lines of code that managed 8 million 56% of reduction in
8 defects in 4 years

Defects / KLOC
claims per year from a client base of 10 million
6
customers. Development of new functionality
suffered as a result of substantial Technical Debt, 4

and was typically accompanied by high defect rates. 2

0
To gain control over Technical Debt and reduce maintenance 2002 2003 2004 2005 2006
costs, the executive in charge of this application mandated
Figure 5. Reduction in Defect Rates for a Large Insurance Application
that future development would be subjected to structural
quality measurement and baseline targets were set for
maintainability. Development teams were held accountable
for making steady progress toward the maintainability targets
release by release, and were presented the results of each
structural quality analysis.



Over the course of four years, they saw the following results:

• Maintainability targets were stabilized against the baseline target even
though the application code base grew by 40%.
• Defect rates in system test and operations fell 56% as Technical Debt
was remediated and the application became easier to understand and
maintain, as shown in Figure 5.
• Delivery time was reduced by 60% as a result of more maintainable code
and less interference from rework.
• Maintenance costs for this application were reduced by 20% within the
first three years.



Case Study
Telco provider reduces outages to save $2.7 million

CAST performed structural analysis of Technical Debt on the billing
system of a large telecommunications company. Management’s
objectives were to reduce rework and outages, as well as gain control
over outsourced maintenance costs. If managing Technical Debt
Anti-patterns
addressed the objectives, then the process would be deployed to Defects
reduce Technical Debt in other critical applications.
R4 R5 R6 R7
Releases
Technical Debt was measured at an initial release and critical violations of good
architectural and coding practice (anti-patterns) were targeted for remediation. Over Figure 6. Reduction in Technical Debt
and Defects across Releases
the subsequent three releases, the anti-patterns constituting Technical Debt were
steadily reduced, as shown in Figure 6. Along with this reduction in Technical Debt
was a highly correlated reduction in system test and operational defects. A decline in
The effort to remediate Technical Debt is
operational problems was also observed, which was correlated with reductions in
correlated with a reduction in system test
defect rates, although the data were not available to prove a causal relationship.
and operational defects over the next 9
releases until it appears to stabilize at
Based on the successful pilot, structural analysis was deployed to a portfolio of release 11.2. The same pattern was
critical applications to reduce and control Technical Debt. Figure 7 shows structural observed with other applications.
quality analysis was initiated on this particular application at release 8.



Reducing rework by lowering
the number of defects resulted
in a substantial reduction in Code
Non code
maintenance costs.

IT estimated cost savings
of $2.7 million in the first
year on this particular
application as a result of
rework and outage
reductions as well as

R1 1
R8

2
3
R1 .2
R1 .1
R1 0

R1 .2

R1 3
R1 .1
R1

.2

R3

3
R2

R5

R9

.2
R6
.1

R4

R7

.1
.1
.1

.1

4E
R1

R1
1.
R1

R1
0.

1
1
0
0
R1

R9
R1

R9
R3
R2

R7
better management of
R8 - Structural Quality Analysis starts here
outsourced services.

Figure 7. Defect Volume Reduction across Releases


V: Conclusion

Technical Debt provides a way to apply financial terms to the risks inherent in
applications that have structural flaws in code caused by violations of good
architectural and coding practices. For those with executive responsibility for
governing the costs and risks of an application portfolio, the Technical Debt
Management Cycle provides a clear process for measuring and managing
Technical Debt that can help in balancing IT and business priorities, and over
time reduce the risk of failure of critical applications.

By following this 7-step process, an organization can
weigh the costs of remediation against the expectation
Author
of achieved benefits—and ultimately pay down the
Dr. Bill Curtis, Senior Vice President
interest of the overall liability inherent in the portfolio. and Chief Scientist, CAST

For a more detailed overview on the concept of Technical Debt, please
download our white paper “Paying Down the Interest on Your Applications: A
Guide to Measuring and Managing Technical Debt.”


VI. About CAST

Call: 877-852-2278
Connect with us:
Email: info@castsoftware.com

Visit our Web site: www.castsoftware.com

CAST is a pioneer and world leader in Software Analysis and Measurement, with unique
technology resulting from more than $100 million in R&D investment. CAST introduces
fact-based transparency into application development and sourcing to transform it into a
management discipline. More than 250 companies across all industry sectors and
geographies rely on CAST to prevent business disruption while reducing hard IT costs.
CAST is an integral part of software delivery and maintenance at the world's leading IT
service providers such as IBM and Capgemini.

Founded in 1990, CAST is listed on NYSE-Euronext (Euronext: CAS) and serves IT intensive
enterprises worldwide with a network of offices in North America, Europe and India. For
more information, visit www.castsoftware.com


7 Steps to Pay Down the Interest on Your IT Technical Debt

More Related Content

What's hot (20)

Similar to 7 Steps to Pay Down the Interest on Your IT Technical Debt (20)

More from CAST (20)

Recently uploaded (20)

7 Steps to Pay Down the Interest on Your IT Technical Debt