Why you should stop using the generic term “Technical Debt” and start resolving specific problems instead
2 likes128 views
The document argues against the generic use of the term 'technical debt' and emphasizes the need to address specific problems instead. It outlines how frequent rewrites are often counterproductive and suggests that developers should focus on incremental improvements while delivering business value. The author advocates for tracking specific issues, understanding their impacts, prioritizing resolutions based on business needs, and continuously refactoring code as part of the development process.
Why you should stop using the generic term “Technical Debt” and start resolving specific problems instead
- 1. Why you should stop using the generic term Technical Debt And start resolving specific problems instead! by Oleksii Fedorov @ Pivotal 1
- 2. Why you should stop using the generic term Technical Debt 2 This code sucks! Let me rewrite it to this new JS framework!Is it really that bad?
- 3. Why you should stop using the generic term Technical Debt 3 “We have so much technical debt! We don’t even know how to start fixing it!”
- 4. Why you should stop using the generic term Technical Debt 4 Why rewrite is 99.99999% a bad idea • Business valuable features will be put on hold • If not, then rewrite will have to “race” with the old system. It is going to end up with more issues. • Executing a good rewrite requires certain skills. Are you sure your team has them?
- 5. Why you should stop using the generic term Technical Debt 5 Skills needed for a good rewrite • Good, non-over-engineering, software design skill • Skill for back-filling of tests for existing code • Test-driven development skills • Mastery of clean code • etc.
- 6. Why you should stop using the generic term Technical Debt 6 Developer with such profile • software design skill • patient back-filling tests skill • TDD skills • Clean code • etc. Will not complain about technical debt
- 7. Why you should stop using the generic term Technical Debt 7 They will just refactor code they touch all the time, bit by bit WHILE delivering business-valuable functionality
- 8. Why you should stop using the generic term Technical Debt 8 “So when should we do the rewrite?”
- 9. Why you should stop using the generic term Technical Debt 9 Almost never.
- 10. Why you should stop using the generic term Technical Debt 10 Make incremental changes towards the goal all the time.
- 11. Why you should stop using the generic term Technical Debt 11 “How?!”
- 12. Why you should stop using the generic term Technical Debt 12 Ugh. I don’t know. So what is the issue you are currently facing?
- 13. Why you should stop using the generic term Technical Debt 13 It is just so outdated
- 14. Why you should stop using the generic term Technical Debt 14 It is so convoluted
- 15. Why you should stop using the generic term Technical Debt 15 Hundreds of tests break on every change
- 16. Why you should stop using the generic term Technical Debt 16 Somebody else wrote this
- 17. Why you should stop using the generic term Technical Debt 17 This library is taking more time than saving us
- 18. Why you should stop using the generic term Technical Debt 18 I don’t like this framework
- 19. Why you should stop using the generic term Technical Debt 19 <INSERT YOUR OWN EXCUSE>
- 20. Why you should stop using the generic term Technical Debt 20 …. Why is that?
- 21. Why you should stop using the generic term Technical Debt 21 What should have been a “1-pointer” turned out to be a “3-pointer” And how is that a problem for us?
- 22. Why you should stop using the generic term Technical Debt 22 Whenever we touch this module we deliver 10-20 bugs And how is that a problem for us?
- 23. Why you should stop using the generic term Technical Debt 23 Now we are talking! bonus points if you could distinguish complaints from real problems.
- 24. Why you should stop using the generic term Technical Debt 24 What just happened? 1. Talk about a specific problem at hand (instead of a generic complaint/feeling) 2. Figure out the reason behind the problem (5 WHYs) 3. Talk about real specific impacts of a problem (e.g., unexpected complexity slowing team down, screwing with estimates, harming mental health of team members, etc.) 4. Start tracking all of the above
- 25. Why you should stop using the generic term Technical Debt 25 “I know which problems are serious. Now what?”
- 26. Why you should stop using the generic term Technical Debt 26 Identify which problems are worth fixing
- 27. Why you should stop using the generic term Technical Debt 27 Wishlist So this module, to which product area it belongs? No need to fix it now then
- 28. Why you should stop using the generic term Technical Debt 28 Hold on. It also affects shopping cart heavily! Well. This IS a problem! Let’s decouple them
- 29. Why you should stop using the generic term Technical Debt 29 “Product areas?”
- 30. Why you should stop using the generic term Technical Debt 30 Yep. We need to think about these problems through the lenses of Product as well.
- 31. Why you should stop using the generic term Technical Debt 31 Identify product areas that you have Wishlist Checkout Shopping cart Offers search/filter And more…
- 32. Why you should stop using the generic term Technical Debt 32 How much more value business will gain if it could work in Area X twice as fast? Wishlist Checkout Shopping cart Offers search/filter And more… 1 4 5 5
- 33. Why you should stop using the generic term Technical Debt 33 On a horizon, how frequent business wants to change Area X? Wishlist Checkout Shopping cart Offers search/filter And more… 1 4 5 5 frequent frequent rare maintenance
- 34. Why you should stop using the generic term Technical Debt 34 What problems do we have in the Area X and how severe they are? Offers search/filter 4 frequent Shopping cart 5 frequent Checkout 5 rare Wishlist 1 maintenance • bad library Z • flakey test suite • etc. • too coupled with Wishlist • low test coverage • etc. • Filtering is very slow • Tests are too coupled • etc. • Very long methods • etc.
- 35. Why you should stop using the generic term Technical Debt 35 Now you should prioritise these problems And start scheduling them in iterations
- 36. Why you should stop using the generic term Technical Debt 36 And one last anecdote
- 37. Why you should stop using the generic term Technical Debt 37 BTW, today I’ve been working on this feature for checkout product area Yeah, what’s up with it? I’ve split one of the long methods while working on it. Everybody on the team is happy!
- 38. Why you should stop using the generic term Technical Debt 38 “And, most importantly I’ve understood how Checkout works much more than ever before!”
- 39. Why you should stop using the generic term Technical Debt 39 Let’s recap 1. Track specific problems, their WHYs, and their impacts on team/business 2. Track importance of product areas 3. Be aware of how issues affect product areas 4. Prioritise most impactful problems (max ROI) and schedule 1-2 for your next iteration 5. Refactor small issues “inline” while delivering (Campsite rule: “Leave campsite cleaner than you’ve found it”)
- 40. Why you should stop using the generic term Technical Debt 40 Thank you! Q & A time! Learn more about technical debt and more at ThroughLensesOfCTO.com