Richard’s Technical Debt
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.
- 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
- do a “technical debt sprint”
- “Boy Scout Rule”
- 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)
- Really useful
- Still need to be managed properly
- 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
- 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
- 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
Technical debt can be a good thing, but bad code never is.