The document discusses the concept of technical debt, which refers to design compromises or shortcuts taken when developing software that result in technical quality issues down the line. It notes that some level of technical debt can be acceptable as an investment if incurred proactively, and discusses strategies for managing debt like test-driven development, refactoring, and prioritizing fixes for the most expensive issues. The key messages are to only take on debt when necessary, track and pay it down over time through refactoring, and limit work in progress to avoid accumulating too much debt.

1. © 2011 VersionOne 1
Managing Technical
Debt

2. © 2011 VersionOne 2
Let’s Talk

3. © 2011 VersionOne 3
What is Technical Debt
• Design Compromises
• Choosing to accept something as “done” before its time

4. © 2011 VersionOne 4
Technical debt is not always represented by
Defects
public void populateList(String food)
{
Food SelectedFood = new Food();
if(food.equalsIgnoreCase("vegetable"))
{
SelectedFood = new Vegetables();
}
else if(food.contains("Legume"))
{
SelectedFood = new Legume();
}
list.setAdapter(mSchedule);
}

5. © 2011 VersionOne 5
But it usually results in them

6. © 2011 VersionOne 6
Is technical debt always bad?
• Just as in finance, sometimes taking on a certain level of
debt can be considered an investment.
– This needs to be a decision that is made proactively, not
reactively

7. © 2011 VersionOne 7
Is a debt free project even possible?
• Mentality of Sufficiency – Perfect is the natural enemy
of Good

8. © 2011 VersionOne 8
When might debt be ok?
• New architecture
– Perhaps we want to do our migration to the new architecture one
step at a time. Until we have completed the migration we are
choosing debt
• First to Market
– Sometimes, the monetary effect of being first to market is worth
incurring some debt

9. © 2011 VersionOne 9
Some common ways to incur debt
• Time pressure
– We don’t have enough time to finish, unless we cut some corners
• Competitive pressure
– If we can at least show this feature, we will beat the competitor
to market

10. © 2011 VersionOne 10
How might we avoid taking on too much
debt?

11. © 2011 VersionOne 11
Test Driven Development

12. © 2011 VersionOne 12
Acknowledging the interest rate
• There is a cost to waiting
• Understand what that cost is and call it out
• Remember that interest compounds

13. © 2011 VersionOne 13
Paying off inherited debt (legacy code)
• Start small, creating tests around any work we do within
the legacy code base
• We own this debt just as much any debt we choose to
take on.

14. © 2011 VersionOne 14
Refactoring – paying a little at a time
• All debt has a minimum payment, or “debt service”
• We can pay our debt service through improving the design
whenever we are in our code, without changing the
behavior
– Find a place that could use some improvement
– Wrap the change in tests
– Make the change
– Run the tests
• Its ok to pay a little extra, but don’t go overboard

15. © 2011 VersionOne 15
Some strategies for spending within your
means
• Keep your stories small
• Only sign up for what you can comfortably accomplish
• Stick to your guns, only agree to debt that you can be
comforatable with

16. © 2011 VersionOne 16
Don’t take on more than you can pay

17. © 2011 VersionOne 17
Limited WIP and Kanban
• By constraining how much work we take on at one time
we can focus on quality
• Pull oriented processes mean less incentive to “cram
something in”

18. © 2011 VersionOne 18
Iterative Development and Velocity
• As we identify a cadence and velocity, we see how much
we really can sign on for
• Tight feedback loops give us room to inspect and adapt

19. © 2011 VersionOne 19
Pay the Biggest interest items first
• Make debt service on all debt
• As you fix the more expensive items, you are freeing up
resources for the less expensive items later

20. © 2011 VersionOne 20
Debt Restructuring
• Sometimes, but *very* seldom, we have to declare
bankruptcy – Major Rearchitecture
• A better approach is to create a restructuring plan
• A set of payments (backlog items or defects) that are
scheduled at regular intervals, and with higher priority or
Class of Service than new features

21. © 2011 VersionOne 21
Alternative ways to consider debt
• Choose a metaphor that resonates
• Not everyone is comfortable with the money theme

22. © 2011 VersionOne 22
Speedboat
• Our product is a speedboat, heading for an exotic harbor
• Our debt is a set of anchors
– Each anchor has a weight associated with the amount of work
to be done
– Each anchor is a different depth, loosely analogous to how long it
will take to pull the anchor up

23. © 2011 VersionOne 23
Some basic tips

24. © 2011 VersionOne 24
Recognize your debt
• Don’t sweep it under the rug
• “It goes without saying” doesn’t

25. © 2011 VersionOne 25
“Borrow” only when absolutely necessary
• Don’t let It become a habit
• By thinking of it as a necessary evil, we can make it
something that is an exception instead of a rule

26. © 2011 VersionOne 26
Track debt
• Note the “interest rate”
• Calculate the costs at periodic intervals

27. © 2011 VersionOne 27
Plan to pay your debt, just like you plan for
new features

28. © 2011 VersionOne 28
Don’t beat yourself up
• We all borrow
• Sometimes we let our borrowing get away from us
• Recriminations do NOTHING to get the debt paid off

29. © 2011 VersionOne 29
Remember, you can pay me now, or you can
pay me later…