Technical Debt and What to do about it.

Kane MarCertified Scrum Trainer and Coach (CST and CSC)

http://KaneMar.com

Kane.Mar@gmail.com

About Me, About You

What is Technical Debt

The concept of software complexity as debt was originally coined by Ward Cunningham in an experience report for OOPSLA ‘92 (*)

Reference: http://c2.com/doc/oopsla92.html

What is Technical Debt

During the planning or execution of a software project, decisions are made to defer necessary work:

It's too late in the LifeCycle? to upgrade to the new release of the compiler. We'll do it next time around.

We're not completely conforming to the UserInterface guidelines. We'll get to it next time.

We don't have time to uncruft (refactor, see RefactorMercilessly) the hyper-widget code. Punt until next time.

What is Technical Debt

A big pile of deferred work can gum up a project, yet many of the items on the list don't appear on a project team's radar, especially if the focus is primarily on new product features. Yet removing accumulated sludge needs to be accounted for in planning!

Therefore: Make the debt visible. Keep an explicit list Technical Debt

0

12.5

25.0

37.5

50.0

1 2 3 4 5 6

Correlation between declining quality and velocity

Category Title

% MaintenanceVelocity of New Development (PBI/$100k)

0

500

1000

1500

2000

1 2 3 4 5 6

New Requirements Capability

Req

uire

men

ts

Category Title

Quality and Velocity

The story of a burger ...

How does “Technical Debt” occur?

By not enforcing high quality standards in the definition of “done.”

Cutting corners to achieve a higher velocity and meet impossible timelines leads to build up of low quality, unmaintainable code.

Death spiral: As the maximum velocity of system goes down, even more corners are cut to compensate until the velocity approaches zero.

Signs of Technical Debt

The code is considered part of a core or legacy system

There is either no testing, or minimal testing surrounding the code

There is highly compartmentized knowledge regarding the core/legacy system, and it may be supported by only one or two people in the company (over specialization)

Signs of Technical Debt

The legacy system is not in a know state

It takes as long to fix defects caused be adding new functionality, as it does to add the new functionality

Re-platforming ... and then repeat the mistakes of the past

What to do about Technical Debt

Avoid accumulating technical debt

Pay it off over time (mortgage)

“Working with legacy code” by Michael Feathers

An anti-pattern worth mentioning

Avoid Technical Debt

Development teams must curb over-optimism in assessing availability and capacity

Management redirects attention from applying pressure to removing organizational impediments to progress

Product Owners understand the iron triangle, ownership of risks, and impact of cutting quality

ScrumMaster must prevent demonstration of any work that is not “done”

Paying off Technical Debt

Described by Michael Feathers in “Working Effectively with Legacy code”

Start by introducing Continuous Integration

Write Tests around customer reported defects

Over a period of time a testing framework will be built up around the most brittle code

And Avoid this anti-pattern

There is a temptation to try and write a comprehensive testing framework around the entire product

Does not address the defects that the customer views as most important

May run out of money before you complete the framework

Thank you!