Technical Debt

University of Southern California

Center for Systems and Software Engineering

Technical Debt

CS 510 Software Engineering

Supannika Koolmanojwong



Outline

• Total Cost of Ownership• Technical Debt

2



What are the cost of a software?

• Think about the whole life cyle

3



Total cost of ownership

• a financial estimate whose purpose is to help consumers and enterprise managers determine direct and indirect costs of a product or system.

– including the costs to research, develop, acquire, own, operate, maintain, and dispose of a system

4



Potential total cost of ownershipComputer hardware and

programsOperation expenses Long term expenses

• HW and SW• Network• Server• Workstation• Installation & integration

• Purchasing research• Warranties and licenses• License tracking -

compliance• Migration expenses• Risks: susceptibility to

vulnerabilities, availability of upgrades, patches and future licensing policies, etc.

• Infrastructure• Electricity• Testing costs• Downtime, outage and

failure expenses• Diminished performance• Security (including

breaches, loss of reputation, recovery & prevention)

• Backup and recovery process

• Technology training• Audit• Insurance• IT personnel

• Replacement• Future upgrade or scalability

expenses• Decommissioning

5



6



Relative* Total Ownership Cost (TOC)For single system life cycle (TOC-SS)

Cycle 1 Cycle 2 Cycle 3 Cycle 4 Cycle 50.00%

50.00%

100.00%

150.00%

200.00%

250.00%

Project A Project B Project C

~5% architecture investment



* Cumulative architecting and rework effort relative to initial development effort



Technical DebtCode Debt

DESIGN DEBT

Deficit programming

Technical Inflation

CodeSmell

Software Decay

coined by Ward Cunningham



Technical DebtBy Ward Cunningham

• http://www.youtube.com/watch?v=pqeJFYwnkjE&feature=player_embedded#!

9

http://www.youtube.com/watch?v=pqeJFYwnkjE&feature=player_embedded

http://www.youtube.com/watch?v=pqeJFYwnkjE&feature=player_embedded



Technical Debt

• “is a measure of how untidy or out-of-date the development work area for a product is”

• Not the deferred requirements

http://www.c2.com/cgi/wiki?TechnicalDebt10

http://www.c2.com/cgi/wiki?TechnicalDebt



Technical Debt• “I don’t know what happened, I just

changed one line”• “We can’t upgrade, It will break”• “We can’t upgrade the code, we don’t have

time”• “We can’t upgrade the code, no one

understands it” • “Just put in the comment XXX, we will do it

later” • “Just put in the TODO comment”

http://petdance.com/perl/technical-debt 11

http://petdance.com/perl/technical-debt



Financial debt vs Technical Debt

Interest payments extra effort in future development because of the quick and dirty design choice

continue paying the interest

suffer for performance, problem is still there

pay down the principal refactoring the quick and dirty design into the better design; also reduce interest payments in the future

http://martinfowler.com/bliki/TechnicalDebt.html12

http://martinfowler.com/bliki/TechnicalDebt.html



http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf13

http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf



Technical Debt

• intentional technical debt– cost to taking short cuts

• unintentional technical debt– making mistakes– Conscious decision to optimize for the “present”

rather than the “future”• cost of not dealing with these short cuts and

mistakes will increase over time.

Read more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phjvB5A914

http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html



Common causes of technical debt

• Business pressures• Lack of process or understanding• Lack of building loosely coupled

components (hard-coded)• Lack of documentation• Parallel Development• Delayed Refactoring

http://en.wikipedia.org/wiki/Technical_debt15

http://en.wikipedia.org/wiki/Technical_debt



Technical DebtArchitecture or the platform technology mistake

• Scalability, reliability• Foundations are poorly design• you don’t find out until too late (operations phase)• no choice but to start again or rewrite big chunk

to keep it working

Read more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUV 16




Technical DebtError-prone code

• “ .. If I change X, it is going to break Y, I think ..”• “ Don’t touch that code, last time we did, we

spent a week fixing it…”• 20% of the code where 80% of bugs are found• Hard to understand• Dangerous to change because done poorly one

in the first place• Not rewriting this code is one of the most

expensive mistakes that developers makeRead more: http://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html#ixzz1phnGFlUVhttp://petdance.com/perl/technical-debt/technical-debt.007.html

17


http://petdance.com/perl/technical-debt/technical-debt.007.html



Technical DebtNot easily tested

• “ .. I thought we had a test for that ..”• Don’t have good automated tests• Tests keep falling apart when you change the

code• Testing costs tend to go up over time as you write

more code





Technical DebtCode that mysteriously works

• nobody is sure how or why• Might be written by the geek who left the

company• if nobody on the team understands it, it’s a time

bomb





Technical DebtOthers

• Forward and backward compatibility– Short term debt

• Duplicate, copy-and-paste code– How many ? Trackable ?

• Hard coding• Out of date documentation

– “We just lost the drive, where are the backups” – If nobody is using it, get rid of it. If people are using it,

why isn’t it up to date?





Technical Debt Cost

Debt(in man days)

cost_to_fix_duplications + cost_to_fix_violations + cost_to_comment_public_API + cost_to_fix_uncovered_complexity + cost_to_bring_complexity_below_threshold + cost_to_cut_cycles_at_package_level

http://docs.codehaus.org/display/SONAR/Technical+Debt+Calculation

average $3.61 to $5.42 per line of code.

Example of Technical Debt Calculation

21

http://docs.codehaus.org/display/SONAR/Technical+Debt+Calculation



Technical Debt Observations“Agile Project Management”, Jim Highsmith, second edition

22



70%

85%

95%Committed Costs

Cost to Extra

ct

Defects

3X-6X

20X-100X

500X-1,000X

The Cost of Undetected Defects

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Cum

ulat

ive

Perc

enta

ge o

f Life

-Cyc

le C

ost

15%

Design

20%

Development 50%

Production/Test

100%

Operation Disposal

Concept

8%

Reference: Defense Systems Management College (DAU)Time23



Analysis Design Implementation Test Integration

Development Cost(Perfect World)%

Effo

rt p

er P

hase

24




Defect Insertion Defect detection & Removal

DesignDefects

IntegrationDefects

Typical Defect Profiles

ImplementationDefects

Classification of Defects

25




Development Cost(Real World)%

Effo

rt p

er P

hase

26




Development Cost%

Effo

rt p

er P

hase

Real world Perfect World 27




Development Cost%

Effo

rt p

er P

hase

TechnicalDebt?

TechnicalDebt?

TechnicalDebt?

TechnicalDebt?





Development Cost%

Effo

rt p

er P

hase

TechnicalDebt?

TechnicalDebt?





COTS Integration%

Effo

rt p

er P

hase

TechnicalDebt?




Technical Debt

• http://www.youtube.com/watch?v=xyJvDbEjtYw

31

http://www.youtube.com/watch?v=xyJvDbEjtYw

http://www.youtube.com/watch?v=xyJvDbEjtYw



Fixing technical debt

• 80/20 rule– 20% initial build– 80% clean up

32



Fixing technical debt• Big Bang

– no new features for a year? Really? – spend some time cleaning up the mess– Good ?

• Dedicated Team– Have another team dedicated – Good ? 80/20 rule ?

• Boy Scout– remove technical debt little and often– If no tests, add some. If poor test, improve them. If bad code,

refactor it– The boy scout rule – leave the camp cleaner than you found it

http://www.javacodegeeks.com/2011/11/dealing-with-technical-debt.html#ixzz1pjQ8bQpF 33

http://www.javacodegeeks.com/2011/11/dealing-with-technical-debt.html



Fixing technical debt

• Think time & risk & $$$• No gold-plating

– Unnecessary task that no one wants • BigResearchUpFront vs BigDesignUpFront

34



Technical Debt vs Agile : Bad

• Quick and dirty approach• Scalability vs DoTheSimplestThingThatCouldPossiblyWork

– Just-in-time Scalability• change the architecture in response to actual

customer demand– Wasted Code

http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html 35

http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html



Technical Debt vs Agile : Good

• Get feedback faster• Smaller batches





Technical Debt vs Lean : Good

• Less waste, less debt• Just-in-time nature





Technical Debt vs NDI : Bad

• Product Development Leverage– Your product is fortified by others

• Open-source, COTS, Services• Pros: Faster• Cons

– Code understanding– Different coding styles, architecture, quality– No direct control





http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf39




40http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf




41http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf




Information Categories - Measurable Concepts

Process Performance• Process

Compliance• Process Efficiency• Process

Effectiveness Technology Effectiveness• Technology

Suitability• Technology

Maturity• Technology

Volatility• Technology

AdoptionCustomer Satisfaction• Customer Feedback• Customer Support

Schedule and Progress• Milestone

Completion• Work Unit Progress• Work Backlog• Incremental

CapabilityResources and Cost• Financial

Performance• Personnel Effort• Environment and

Support ResourcesSize and Stability• Physical Size and

Stability• Functional Size and

Stability

Product Quality• Functional

Correctness• Supportability -

Maintainability• Efficiency• Portability• Usability• Dependability -

Reliability• Security - Safety

Source: “Introduction to PSM Course, Version 7.0”, July 30,2012, Portsmouth, VABob Epps, Technical Debt Workshop, PSM Conference



Information Categories - Measurable Concepts

Process Performance• Process

Compliance• Process Efficiency• Process

Effectiveness Technology Effectiveness• Technology

Suitability• Technology

Maturity• Technology

Volatility• Technology

AdoptionCustomer Satisfaction• Customer Feedback• Customer Support

Schedule and Progress• Milestone

Completion• Work Unit Progress• Work Backlog• Incremental

CapabilityResources and Cost• Financial

Performance• Personnel Effort• Environment and

Support ResourcesSize and Stability• Physical Size and

Stability• Functional Size and

Stability

Product Quality• Functional

Correctness• Supportability -

Maintainability• Efficiency• Portability• Usability• Dependability -

Reliability• Security - Safety

Source: “Introduction to PSM Course, Version 7.0”, July 30,2012, Portsmouth, VABob Epps, Technical Debt Workshop, PSM Conference

Measurable Concept Areas where “Intentional” Technical Debt may

be found



Activities during Operations & Maintenance(O&M)

Analysis Design Imp Test Integ

% E

ffort

per P

hase


% E

ffor

t per

Pha

se


% E

ffort

per P

hase

RFC #1 RFC #2 RFC #3

Syst

em

Com

plex

ity

Time

If each RFC has equal complexity you might expect this

Source: Bob Epps, Technical Debt Workshop, PSM Conference 2012 44





% E

ffort

per P

hase


% E

ffort

per P

hase

AnalysisDesign Imp Test Integ

% E

ffort

per P

hase

RFC #1

RFC #2

RFC #3

Syst

em

Com

plex

ity

Time

Even if each RFC has different complexity , it still would be manageable.If maintainability is measured by the number of systems components changedfor an RFC what is the ideal number of components changed? What dictates this number?

Source: Bob Epps, Technical Debt Workshop, PSM Conference 201245





% E

ffort

per P

hase

Analysis Design Imp Test Integ%

Effo

rt pe

r Pha

se


% E

ffort

per P

hase

RFC #1

RFC #2

RFC #3

Syst

emC

ompl

exity

Time

However, experience shows that evenwhen the RFCs have the same complexitythe “aggregate” complexity of the system causesside effects which complicate future RFCs.

How is the phenomenon managed?

Source: Bob Epps, Technical Debt Workshop, PSM Conference 2012 46




AnalysisDesignImp Test Integ

% E

ffort

per P

hase

RFC #1

Syst

emC

ompl

exity

Time


% E

ffort

per P

hase

RFC #2


% E

ffort

per P

hase

RFC #3


% E

ffort

per P

hase

RFC #4


% E

ffort

per P

hase

RFC # N-1AnalysisDesignImp Test Integ

% E

ffor

t per

Pha

se

RFC # N

When overlapping RFCs occur, coupled with side effects the controlof the baseline(s) are in jeopardy .

47Source: Bob Epps, Technical Debt Workshop, PSM Conference 2012



The bottom line

• Trade off between – Technical Debt– Flexibility (Design for Reuse)– Expedition

48



References

• http://pkruchten.files.wordpress.com/2011/10/kruchten-111027-techdebt.pdf

49



Technical Debt

Documents

Transcript of Technical Debt