Technical debt is something often mentioned on the software development floor - but what is it? and what is it not? how can we capture it to reduce it?

1. What is technical debt?

2. 7th April 2011 Don't Laugh It's Paid For - Mike Burns 2

3. 7th April 2011 Don't Laugh It's Paid For - Mike Burns 3

4. “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 not-quite-right code counts
as interest on that debt”
Ward Cunningham, 1992
7th April 2011 Don't Laugh It's Paid For - Mike Burns 4

5. 1
Cost of change
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
Time Loan
7th April 2011 Don't Laugh It's Paid For - Mike Burns 5

6. 7th April 2011 Don't Laugh It's Paid For - Mike Burns 6

7. Deliberate
Quality softwarehave the leastmust ship of time
“We don’t
takes “We amount
now and deal
to develop. If for have code that is simple as
time you
with
design”
possible, tests that are complete and a design
consequences”
that fits just right, additions and changes
happen in the fastest possible way because the
Reckless Prudent
impact is lowest. Consequently, if you hack
something out, the more you hack the slower
you go because the cost of “Now we knowchange
“What’s addition or
layering?” how we should
grows with each line of done it”
have code.
7th April 2011 Inadvertent 7

8. Deliberate
A bug by itself is not technical ship
“We must debt.
“We don’t have
now and deal
time for is more likely poor
It with
design”
testing, requirements, design, coding, etc;
consequences”
Something within the development
lifecycle, something that we could probably have
Reckless Prudent
fixed before it became a bug.
If bugs continue to appear within
the same
area, function, feature, this may be
a sign of technical debt.
7th April 2011 Inadvertent 8

9.  “Don’t we have docs on the file layouts?”
 “I thought we had a test for that?”
 “If I change X, it’s going to break Y. I think.”
 “Don’t touch that code. Last time we did, we spent a
week fixing it.”
 “We just lost the drive. Where are our backups?”
 “Where’s the email about that bug?”
 “Just put in a comment with XXX.
We’ll see it later.”
 “Just put in a comment with TODO.
We’ll see it later.”
 “Just put in a TODO.
Right about the XXXs.”
7th April 2011 Don't Laugh It's Paid For - Mike Burns 9

11. 7th April 2011 Don't Laugh It's Paid For - Mike Burns 11

12. 7th April 2011 Don't Laugh It's Paid For - Mike Burns 12

13. I don’t know what happened! I just
changed one line!
It's too late in the life cycle to
upgrade to the new release of the We can’t upgrade.
compiler. We'll do it next time It will break code.
around.
7th April 2011 Don't Laugh It's Paid For - Mike Burns 13

14.  Developers?
  who is building what, when, and why
Testers?
 Project Managers?
 add business functionality in deliberate,
 prioritized ways
Upper Management?
 Everyone in the organization
7th April 2011 Don't Laugh It's Paid For - Mike Burns 14

15. 7th April 2011 Don't Laugh It's Paid For - Mike Burns 15

16.  Documentation
 Writing tests
 Attending to TODO comments
 Tackling compiler warnings
 Static code analysis warnings
• Technical Debt wiki can capture:
• Knowledge that isn't shared around the organization
• Code that is too confusing to be modified easily
• Prudent, deliberate design decisions that incur technical debt
• Potential “messes” (or messes that we know already exist!)
7th April 2011 Don't Laugh It's Paid For - Mike Burns 16

17. 7th April 2011 Don't Laugh It's Paid For - Mike Burns 17

18. Even the best teams will have debt to deal with
as a project goes on - even more reason not to
recklessly overload it with crummy code.
7th April 2011 Don't Laugh It's Paid For - Mike Burns 18

19. 7th April 2011 Don't Laugh It's Paid For - Mike Burns 19