technical debt part ii

University of Southern California

Center for Systems and Software Engineering

Technical DebtPart II

CS 577 Software Engineering

Supannika Koolmanojwong



Outline

• Technical Debt – revisit• Technical Debt quadrant• Checklist to prevent Technical Debt

2



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?TechnicalDebt3

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



Symptoms of Technical Debt • Lack of / poor documentation• Untested code• Suppressed errors• Unshared knowledge between teams or people• Confusing code, inconsistencies, “workarounds” • Local changes you’ve not committed• Code that doesn’t follow coding standards• Non-existent or improperly used version control• Unstable deployment process• Duplicate code blocks• Individual code ownership• 3rd party software that needs updated or patched.

4http://naramore.net/slides/DPC10-techdebt.pdf



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 5

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



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_debt6

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



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

7

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

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

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




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?





Analysis Design Implementation Test Integration

Development Cost%

Effo

rt p

er P

hase

TechnicalDebt?

TechnicalDebt?

TechnicalDebt?

TechnicalDebt?

Real world Perfect World 11




Development Cost%

Effo

rt p

er P

hase

TechnicalDebt?

TechnicalDebt?





COTS Integration%

Effo

rt p

er P

hase

TechnicalDebt?




Technical Debt Quadrant

14http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

Somewhat OK …

It lets you hit a deadlineIt lets you test an experimental featureThe code is rarely touchedYour code is at the end of the life-cycle

Not OK…

SloppyLazyCareless




15http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

We know we are taking shortcuts, but we do it anyway

Sometimes we don’t know any better, or the debt is not our fault

- Inexperienced team members- Requirements volatility- Post-release retrospectives- Security patches or updates from 3rd parties

http://naramore.net/slides/DPC10-techdebt.pdf




16http://martinfowler.com/bliki/TechnicalDebtQuadrant.html http://naramore.net/slides/DPC10-techdebt.pdf



To tackle the technical debt

• Discover– Use good practices– Checklist, peer review, V&V

• Estimate• Break Down• Task & Track

17



Managing Technical Debt• Use good technical practices

– TDD, Test automation, continuous integration– Refactoring, risk analysis, V&V

• Use a strong definition of done• Properly understand technical debt economics

– Cost of taking on the debt• Cost of additional work• Interest payment• Cost of delaying the development of future products

– Benefit that we may receive

18http://innolution.com/blog/managing-the-accrual-of-technical-debt



Checklist - Code related

• Well comment? • Follow code style standard ? • Carefully look at overly complex code

– A couple layers of indenting• Follow MVC pattern? • LOC / class or method

– The longer the worse• Duplicate code anywhere ?

19http://www.scrumalliance.org/articles/451-technical-debt-for-pms



Checklist - Platform / architecture / build

• Rely on third party? – When was the last time we upgraded these components?

• Rely on outdated libraries? – May no loner work

• Standard IDE configuration? – What about other developer?

• How long does it take to build ? – Long build – developers lose focus

• Configuration? – Build in one machine ? Need separate machines?

20



Checklist - Test

• Can QA team build / run automated tests?• Any automated testing tools ?• What % of code is covered by automated

test? • How do you do continuous integration?

21



Estimate• Cost of taking on the debt

– Cost of additional work– Interest payment– Cost of delaying the development of future products

• Benefit that we may receive

22http://naramore.net/slides/DPC10-techdebt.pdf



Breakdown

• Loan = cost to fix• Interest rate = adverse impact on development

• Every task breaks down into 2 categories– Debts where we continue paying interest– Debts where we pay the principle

• VB-concept– Paying it off by focusing on the highest interest

rate23



Task and Track

• How can we make it visible?– Bug tracker, task board

24



What Practitioners say about TD

• Short-term benefits versus Long-term Pain– Mostly intentional decisions to tradeoff– Short-term thinking reaction to the pressure– What shortcuts can you make to get the product

out faster resulting in increased complexity, poor performance, low maintainability, fragile code, reliability and stability

25A Balancing Act: What Software Practitioners Have to Say about Technical Debt, Erin Lim, Nitin Taksande, Carolyn Seaman, IEEE Software, Vol. 29, No. 6, 22-27, 2012




• Software Quality versus Business Reality– System’s unpredictability– Cut back some activities - review– On several occasions, technical debt is good

• Deliver on time for the trade show• Catch the shopping window• Prototype to secure investor funding

26




• Customers’ expectations vs Their needs and wants– Customers don’t know what they want, not

clarifying their intention – On the other hand, release product faster to get

customer feedback– Uncertainty over market’s direction

• Becomes technical debt when receive new info

– Commitment to the customer took precedence

27




• Measuring Debt and communicating its consequences– Not easy, impact is not uniform– Usually matter / visible to developers more than

customers– Need to show tangible number to convince

managers– Once they understood TD clearly, they were

cooperative

28




• A coherent code base versus just getting stuff done– Developers see TD as bugs, defects, issues– Managers see TD as risks– People with “getting stuff done” attitude tends

to incur more technical debt

29



Lesson learnedStrategies to deal with TD

• Do nothing – if it ain’t broke, don’t fix it– The debt might not ever become visible to the

customer• Use risk management

– Allocate 10% of each release cycle to address TD

• Customer expectation management– Have open dialogue

• Conduct audit with the whole team and track them

30

technical debt part ii

Documents

software engineering5common

software engineeringcs

b software engineering

peopleconfusing code

todo comment http

dont touch

time bombread

components hardcodedlack