3. DO YOU KNOW THESE
PROBLEMS?
Your team cannot change the system quick enough to
meet changing business needs
Your code is so complex only a few people in the
company are allowed to make changes
Your spend more time fixing defects introduced by
new functionality
You have recently re-platformed to newer technology
4. WHY SHOULD YOU
CARE?
Be able to meet
changing business
needs
Reduce Total Cost of
Ownership
Build higher quality
products
Keep customers happy
5.
6. 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
7. 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
8. HOW DOES TECHNICAL
DEBT HAPPEN?
By not enforcing high
quality standards
Cutting corners to
achieve a higher
velocity to meet
timelines
As the velocity of
system goes down, even
more corners are cut
10. COST OF MAINTENANCE
Cost of Maintenance
Maintenance Cost
0 1 2 3 4 5 6 7 8 9
Release
11.
12. 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 ... the legacy system is not in a
know state
There is highly compartmentalized knowledge
regarding the core/legacy system, and it may be
supported by only one or two people in the company
(over specialization)
13. SIGNS OF TECHNICAL
DEBT
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
14.
15. 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”
16. AVOID TECHNICAL DEBT
Implement the Agile
Technical practices:
Continuous
Integration
Test Driven
Development
Refactoring
Pair Programming
17. STRATEGIES FOR PAYING
TECHNICAL DEBT
Two strategies to
consider:
Highest interest rate
first approach
Lowest balance first
approach
18. PAYING OFF TECHNICAL
DEBT
Described by Michael Feathers in “Working
Effectively with Legacy code”
Start by introducing Continuous Integration
Write Automated Tests around customer reported
defects
Over a period of time a testing framework will be
built up around the most brittle code
19.
20. AND AVOID THIS ANTI-
PATTERN
There is a temptation to try and write a
comprehensive testing framework around the entire
product, but:
This does not address the defects that the customer
views as most important
You may run out of money before you complete
the framework, and
You are not delivering new business value
21. IN CLOSING ...
By focusing on reducing technical debt, we can:
Better meet changing business needs
reduce Total Cost of Ownership
Build higher quality products
Keep our customers happy
