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.