How to measure technical debt and when to pay it
Technical debt is not always bad. A practical way to decide which debt to pay and when, based on business impact.
Set up badly, code review becomes the slowest step in a team. Set up well, it raises both quality and shared knowledge.
What should a reviewer look at?
Formatting and style belong to automated tools. Human attention belongs on these questions: does the change really solve the problem, what happens on failure, is the permission check in the right place, and will someone reading this in a year understand it?
How big should changes be?
With a large change the reviewer tires and approves. Changes with a single purpose and no more than a few hundred lines are reviewed both faster and more carefully. Feature flags make it possible to split large work.
How should comments be written?
Make it clear whether a comment is required or a suggestion. Talk about the code rather than the person, and give the reason. If a debate goes past three rounds, a short call is usually better.
How do you reduce waiting?
Agree a response target within the team, for example first feedback the same working day. Making pending reviews the first job of the day creates more value than opening new work.
