Technical Debt Part II

University of Southern California

Center for Systems and Software Engineering

Technical DebtPart II

CS 577 Software Engineering

Supannika Koolmanojwong

University of Southern California

Center for Systems and Software Engineering

Outline

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

2

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

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

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

University of Southern California

Center for Systems and Software Engineering

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?

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

University of Southern California

Center for Systems and Software Engineering

Analysis Design Implementation Test Integration

Development Cost%

Effo

rt p

er P

hase

TechnicalDebt?

TechnicalDebt?

TechnicalDebt?

TechnicalDebt?

Real world Perfect World 11

University of Southern California

Center for Systems and Software Engineering

Analysis Design Implementation Test Integration

Development Cost%

Effo

rt p

er P

hase

TechnicalDebt?

TechnicalDebt?

Real world Perfect World 12

University of Southern California

Center for Systems and Software Engineering

Analysis Design Implementation Test Integration

COTS Integration%

Effo

rt p

er P

hase

TechnicalDebt?

Real world Perfect World 13

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

Technical Debt Quadrant

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

University of Southern California

Center for Systems and Software Engineering

Technical Debt Quadrant

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

University of Southern California

Center for Systems and Software Engineering

To tackle the technical debt

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

• Estimate• Break Down• Task & Track

17

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

Task and Track

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

24

University of Southern California

Center for Systems and Software Engineering

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

University of Southern California

Center for Systems and Software Engineering

What Practitioners say about TD

• 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

University of Southern California

Center for Systems and Software Engineering

What Practitioners say about TD

• 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

University of Southern California

Center for Systems and Software Engineering

What Practitioners say about TD

• 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

University of Southern California

Center for Systems and Software Engineering

What Practitioners say about TD

• 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

University of Southern California

Center for Systems and Software Engineering

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