A backlog item called ‘refactor the platform’ gives a business owner very little to work with. Which customer change does it unlock? What will remain difficult if the work is postponed? A useful technical debt discussion starts with an observable constraint and ends with a bounded piece of work.
Describe the cost of leaving it alone
Consider an illustrative ordering system where adding a delivery option requires changes in checkout, invoicing, and support tools. Record the repeated work and the places where rules disagree. The argument for improvement becomes a specific dependency problem, rather than a judgment about whether the code looks modern.
Martin Fowler’s technical debt quadrant distinguishes deliberate trade-offs from problems discovered through experience. That distinction helps a review stay constructive: a decision can have been reasonable when it was made and still need revisiting.
Fund a change with a finish line
Propose extracting the delivery rule behind one interface, protecting existing behavior with tests, and migrating one consumer. Define completion in terms of what the next delivery change will require. Avoid turning the work into permission to reorganize every nearby module.
Compare that proposal with keeping the current design for another quarter. Include the effort of migration and temporary duplication, as well as the expected reduction in repeated work. If the area changes rarely, documenting the constraint may be enough.
Check whether the next change became easier
After delivery, review an actual follow-up change with the engineers who implement it. Did fewer components need editing? Was ownership clearer? Were fewer special cases passed to support? Keep that evidence with the original decision so the next maintenance discussion starts from experience.
