Technical Debt

Every time Rohan asks for a new discount rule, the checkout team says it will take three days, and every time he asks why such a small change takes so long. The answer is that the order-total calculation was copied into three places two years ago to hit a deadline. Now every change has to be made three times and tested three ways.

The rule

Price debt by the pain it causes; repay a little every sprint.

Technical debt is the future cost of shortcuts in code and systems. Some is taken on deliberately ("copy it now, clean it up after the sale"); some builds up as the team learns better ways or the product outgrows its design. Like money, it charges interest: extra time whenever you work nearby, more bugs, slower onboarding and more incidents.

Not all debt is worth repaying. Ugly code that nobody touches charges almost no interest. Code the team changes every sprint may be charging a fortune.

The engineering manager's part:

• Make it visible. Keep a short debt list, the way you keep a risk list.
• Translate it into business terms. "The code is messy" persuades nobody. "Discount changes take three days instead of one, and this caused two pricing bugs last quarter" does.
• Budget steadily. A regular share of each sprint, often 15 to 20 per cent, works better than a dramatic rewrite promised for "someday".
• Repay where you are already working. When a feature touches a messy area, clean up that area as part of the feature.
• Record deliberate debt. A shortcut taken on purpose gets a note: what we skipped, why, and when we plan to repay it.

The shortcut

Use the interest test: how often do we touch it, and what does each touch cost? Touched often and costly means repay now. Rarely touched means leave it alone.

Drills

Answer fast — trust the rule.

Remember

• Price debt by the pain it causes; repay a little every sprint.
• Interest test: how often do we touch it, and what does each touch cost?
• Translate debt into business terms, and record any shortcut you take on purpose.