Technical debt refers to aspects of code and development that hinder long-term productivity, including unclear or duplicated code, lack of automation, and outdated documentation. Addressing technical debt is crucial as it affects feature costs, planning, and overall software delivery. Embracing practices like maintaining a tech backlog and incorporating improvements during feature development can help manage technical debt effectively.

1. Lessons learned in surviving to
Technical Debt

2. What is technical debt? 🤔

3. Anything about our code
and our development
environment that slows us
down over the long term 🐌

4. • Unclear code 🤯
• Duplicated code
• Code that is difficult to test

5. Lack of automation 🤖
(anything that we could automate but we
do manually today)

6. • Complex dependencies
• Strong coupling with other systems
we don’t “own”

7. • Long-lived branches
• Lack of continuous integration
• Long build-test cycle
• Lack of test environments

8. • Slow, ineffective tools
• Important documentation that is
missing or out-of-date
• Unnecessary documentation that is
being maintained and kept up-to-
date 📜

9. Other names for technical debt:
• legacy code (valuable code that
we feel afraid to change 😱)
• accidental complication

10. Why should we care about
technical debt? 🤔

11. Because the cost of a
feature is strongly
influenced by the tech
debt we have 💸

12. Technical debt may have
a bad influence on
• planning
• morale
• defects
• delivering visible,
working sw at a
steady pace

13. Lesson learned in tackling the
technical debt

14. We can live with technical
debt, as long as we can
afford to pay the interest,
and as long as the debt
doesn’t grow out of control
https://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt

15. Visualize the technical debt

16. Keep a “tech backlog” and agree
on a team policy to include at least
one of these improvement items in
the sprint backlog

18. our “tech debt backlog”

21. Don’t treat technical debt reduction
as a separate activity from the
feature development ⚠

22. Improve code and tools while
developing a feature / making a change

23. Opportunistic refactoring (*)
(*) refactoring is a simple, regular process of keeping the code clean, easier to understand and easier to change.

24. Embrace the boy scouts rule:
“Always leave the campground
cleaner than you found it.” 🏕

25. Reducing technical debt is not a
linear process

26. Be aware that the branching
strategies have a negative impact
on opportunistic refactoring

27. Review the De
fi
nition of Done to
include a “good scouts rule” 🤞

28. Review the De