Richard’s Technical Debt

25th February 2017

These are my notes from listening to the recording of Richard Banks’ talk The Technical Debt Prevention Clinic that he gave recently at the Microsoft Ignite Australia 2017 conference.

TL; DR - This is a really compelling talk. Go watch it, and share it with your colleagues!

My notes and highlights follow. These are not a substitute for watching/listening to the talk, and the best thing (if you ever get the opportunity) would be to see Richard deliver this in person.

Technical debt

• Is design complexity + cognitive load. Is NOT quick & dirty code
• Bad code is not technical debt, it’s just bad code
• Quantifying – look at trends over time
• Don’t
  • do a “technical debt sprint”
  • Rewrite
• Do
  • “Boy Scout Rule”

Refactoring

• Micro-refactoring – do anytime
• Macro-refactoring – plan and only do one at a time to limit disruption to team
• Both should have tests in place – ideally behavioural tests (so you’re testing the behaviour not the implementation)

Feature flags

• Really useful
• Still need to be managed properly

Preventing

• Be Professional – you don’t need permission to do your job properly
• Have a Definition of Done and stick to it.
• Automate everything you can
  • tests
  • code styles/rules
• Change Team Culture

Code Reviews (suck)

• Traditional code reviews often don’t work well for a number of reasons
• Try doing peer refactoring
• Or pair programming when it is “strong-style” where both people are engaged.
  • Put the mouse away!
• Mob programming – maximise team intelligence
• Experiment and find out what works for your team

Other tips

• Avoid branching if possible. If not possible make it short-lived. This is because merging is costly
• Premature optimisation
• Resist temptations
• Shared learning
• Run hackathons
• Adhere to that Definition of Done

Conclusion

Technical debt can be a good thing, but bad code never is.