Technical debt is something that most project teams or independent developers have to deal with – we take shortcuts to push out releases, deadlines need to be met, quick fixes slowly become the standard. In this talk, we will discuss what technical debt is, when it is acceptable and when it isn’t, and strategies for effectively managing it, both on an independent and team level.

1. Technical Debt
Elizabeth Naramore
Open Source Bridge
June 2011

2. (Me.)

3. Technical Debt
1. What is it?

4. Technical Debt
2. Why should we
care?

5. Technical Debt
3. What do we do
about it?

6. “Shipping first time code is like going into debt. A little
debt speeds development so long as it is paid back
promptly with a rewrite...
The danger occurs when the debt is not repaid. Every
minute spent on non-quite-right code counts as
interest on that debt.”
--Ward Cunningham, 1992

7. “Shipping first time code is like going into debt. A little
debt speeds development so long as it is paid back
promptly with a rewrite...
The danger occurs when the debt is not repaid. Every
minute spent on non-quite-right code counts as
interest on that debt.”
--Ward Cunningham, 1992

8. “I think that there were plenty of cases where people
would rush software out the door and learn things but
never put that learning back into the program, and
that by analogy, was borrowing money thinking that
you never had to pay it back.... eventually all your
income goes to interest and your purchasing power
goes to zero.”
--Ward Cunningham, 1992

9. “I think that there were plenty of cases where people
would rush software out the door and learn things but
never put that learning back into the program, and
that by analogy, was borrowing money thinking that
you never had to pay it back.... eventually all your
income goes to interest and your purchasing power
goes to zero.”
--Ward Cunningham, 1992

10. 1. What is
Technical Debt?
Code or practices
that will
hinder your progress
in the future.

11. 1. What is
Technical Debt?
Code or practices
that will
hinder your progress
in the future.

12. 2. Why should we
care?
Too much technical debt
can cripple your team
or organization.

13. 2. Why should we
care?
Too much technical debt
can cripple your team
or organization.

14. 3. What can we do
about it?
Easy there, tiger.
We’ll get to that.

15. Where do we
find it?

16. In our own code.
For example...

17. You have technical
debt if you have...
Untested code.

18. You have technical
debt if you have...
Untested code.
How much time is wasted
when changes break stuff
and create more bugs?

19. You have technical
debt if you have...
Suppressed errors.

20. You have technical
debt if you have...
Suppressed errors.
(Psst. This doesn’t really
make the error go away. I’ve
tried.)

21. You have technical
debt if you have...
Confusing code, inconsistencies
& workarounds

22. You have technical
debt if you have...
Confusing code, inconsistencies
& workarounds
How much time has been
wasted trying to sort
through spaghetti code?

23. You have technical
debt if you have...
Legacy code

24. You have technical
debt if you have...
Legacy code.
How much time has been
wasted trying to sift through
cruft?

25. You have technical
debt if you have...
Code that doesn’t follow
standards.

26. You have technical
debt if you have...
Code that doesn’t follow
standards.
Code that is hard to read takes
time to read.

27. You have technical
debt if you have...
Duplicate code blocks.

28. You have technical
debt if you have...
Duplicate code blocks.
Good for quilts. Not so good
for fixing mistakes in code.

29. In things that
affect our code.
For example...

30. You have technical
debt if you have...
•Non-existent or improperly used VCS.
•Unstable deployment process.
•Individual code ownership.
•Lack of documentation.
•Unshared knowledge.
•Third party code that needs updated/patched

31. Guess what?

32. We all have it.

33. Don’t panic.

34. Some
technical debt
is ok.

35. It might make sense
if...
It allows you to hit a deadline.

36. It might make sense
if...
It allows you to experiment.

37. It might make sense
if...
The code is rarely touched.

38. It might make sense
if...
You are coding for reasonable
expectations.

39. It might make sense
if...
Your code is at the end of the life
cycle.

40. This kind of debt
is known as
prudent
technical debt.

41. So when is debt
not ok?

42. All the other times.

43. This kind of debt
is known as
reckless
technical debt.

44. Sometimes we know
we are taking
shortcuts,
but we do it anyway.

45. This kind of debt
is known as
deliberate
technical debt.

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

47. This could come from:
•inexperienced team members
•changing project
requirements
•post-release retrospectives
•security patches or updates
from third parties

48. This kind of debt
is known as
inadvertent
technical debt.

49. 4 ways to classify
technical debt:
prudent vs. reckless
deliberate vs. inadvertent

50. Martin Fowler’s Quadrant

51. Martin Fowler’s Quadrant

52. By minimizing deliberate
debt, we can better handle
inadvertent debt.

53. So now that we know
what it is, let’s move on.
3. What can we do about it?

54. We tackle our debt
with
D.E.B.T.
(see what I did there?)

55. Discover
Where is our
technical debt?

56. Where is our
technical debt?
•Ask your developers
•Use the list mentioned before
•Use software like Sonar

57. Estimate
http://sonarsource.org

58. Sonar

59. Sonar
http://nemo.sonarsource.org

60. Sonar
Apache Jackrabbit:

61. Sonar
Sonar + Technical Debt Plugin

62. Estimate
How much is it costing us?
The Simple-ish Formula
Amount of the “loan” = cost to fix
“Interest Rate” = Adverse impact on
development

63. Estimate
How much is it costing us?
Determining the “interest rate” is hard.
Use estimation techniques that
work for you.

64. Break Down

65. Break Down
What do we do with this mass of technical debt?
All debt breaks down into 2 categories:
1. Debts where we continue to pay interest.
2. Debts where we pay on the principal.

66. Task and Track

67. Task and Track
The key is making it visible.

68. Task and Track
The key is making it visible.

69. Task and Track
Add tasks to bug tracker
Add to task board
Show progress to all

70. Paying it Off

71. Paying it Off
Focus on high interest items
OR
Focus on small tickets

72. Paying it Off
Dedicate time.
• Use time right after a release
• Tech debt iteration/sprint
• Time each day for tech debt
• Refactor as you go
• Use off-season time
• Designated Debt Payer

73. Paying it Off
Keep track of your progress
AND
communicate to all.

74. Prevention

75. Prevention
• Break past habits
• Group consensus & commitment
• Teach your “children” well
• Never file for bankruptcy
• Live within your means
• Anticipate your needs

76. A few words about
change
management.

77. You should read this.

78. Change Management

79. Change Management
1. Direct the rider.

80. Change Management
2. Motivate the elephant.

81. Change Management
3. Shape the path.

82. Want to contact me?
http://naramore.net/blog
@ElizabethN
elizabeth@naramore.net
Freenode IRC: ElizabethN
THANKS!
Image used with permission from Martin Fowler