Technical debt is a metaphor used to describe the additional rework that arises when code is developed hastily to meet deadlines without following best practices. It is similar to financial debt in that it incurs ongoing costs in the form of interest as the code requires more maintenance over time. While some technical debt can be incurred strategically for rapid delivery, too much debt makes the code difficult to work with and change over time. Managing technical debt requires identifying debt through code quality issues, prioritizing repayment through refactoring, and allocating time and resources on an ongoing basis to control the level of debt.

1. Technical Debt

2. Financial Debt & The Metaphor

3. Living is expensive, we incur debts every
second of our lives

5. Financial Debt is not always a bad thing.
It lets us buy what we want, or what we
need to keep us alive at some level.

6. Can be dangerous if the incurred interest
and the debt itself are not payed.

7. Technical Debt is a Metaphor

8. Developed by Ward Cunningham in 1992
to communicate problems due to
“developing not in the right way” with non-
technical stakeholders

9. Technical debt is very similar to Financial debt

10. The Cost

11. Technical debt costs money, time, and
effort, to stakeholders, developers,
companies, and even economies

12. “Most companies have to spend 80% of
their software development budget
maintaining code”
Aaron Ericson, informit.com

13. “High amount of
Technical Debt is
No.1 impediment to
teams being agile.”
Dan Rawsthorne

14. Two Ways of Doing Things

15. Clean & smart way, takes longer to
implement, but makes future changes easier

16. Quick & dirty way, gets you features sooner,
but makes future changes very hard

17. Q. Why should investors accept higher
costs?
Q. Why should investors spend money on
features that don’t deliver business
value?

18. A. Living with technical debt might work
perfectly for customers if it delivers the
desired business value. But this will lead to
an uncontrollable codebase, extremely
specialized developers, and an inflexible
product.

19. Shipping first-draft code is like going into
debt

20. A little debt speeds up development as it is
paid back with a rewrite

21. It’s a question of pay me
now or pay me later

22. Good or bad?

23. Incurring technical debt is a
good idea
If you use it strategically
It will allow rapid delivery to elicit quick
feedback and design improvements.
However, clean code is required to pay this
debt back, therefore code should be
refactored.

24. Incurring technical debt is a
good idea
If the principal amount & interest are smaller
than the investment yield
There are some cases where you won’t
have to pay back the debt, it’s pointless if
the code won’t be touched again.

25. Incurring technical debt is a bad
idea
because having messy code & cutting
quality slows you down in reality. And to
keep up you more a larger mess.

26. Extend the Metaphor

27. Similarities to financial debt
Interest
Every minute spent on not-quite-right code
counts as interest on the debt

28. Paying the Principal
Refactoring is like paying off the principal
debt
Similarities to financial debt

29. Borrowing More Money
Neglecting the design is like borrowing more
money
Similarities to financial debt

30. Bankruptcy
Bankruptcy refers to a situation of
overwhelming debt interest, whereby
progress is halted & a complete rewrite is
necessary
Similarities to financial debt

31. Technical Inflation
It occurs when the current level of the
technology is too old to be compatible with
the industry
Similarities to financial debt

32. Anmesty
Throw-away prototypes, retired projects, &
unusable failures do not have to be repaid
Similarities to financial debt

33. The Symptoms

34. The loss of
productivity
and losing
motivation &
morale

35. Increase in testing, death by manual testing,
if testing takes too long, or the same tests
are repeated on each release debt is at a
critical level

36. Code duplication, Copy & paste
programming leads to update anomalies,
and issues understanding code

37. Fear of changing anything, software so
brittle that devs fear changing anything.
Adding features starts to cost more & more

38. “only he knows how to change this part”
“lets copy & paste this block”
Bad Smells
“If I touch that, everything
will break”
“too many to-dos in this
code”

39. The Types by Scope

40. Unavoidable debt, unpredictable,
unpreventable, the team is not at
fault
“feature change due to legal”

41. Strategic debt, long term, incurred
proactively
“We need to be the first to market!”

42. Tactical debt
A short term hack that will be fixed later

43. Incremental debt
Many small shortcuts, quick & dirty hacks to
meet a deadline, etc
Acts like credit card debt

44. Naïve debt
Irresponsible behaviour, or immature
practices

45. Fixing the Debt

46. Merciless refactoring

47. Clean coding principles

48. Clear definition of done

49. Pair Programming
Test Driven Development
Continuous Integration
Refactoring
Automated Unit Tests
Key Engineering Practices

50. Payment Strategies

51. Debt Repayment
Refactor or replace code

52. Debt Conversion
Replace the current solution with a ‘good,
but not perfect’ solution

53. Pay the interest
Live with the code

54. Pay with Cash
• Create a technical debt backlog alongside
feature backlog
• Spend ½ day per week (10%) on debt
issues