Lesson learned in surviving to Technical Debt

What is Technical Debt? Why should you care? How to tackle it?
These are a couple of lessons learned that I want to share.

Transcript

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 fi