How to pay off (technical) debt

Experienced engineers and longtime readers of this column understand the importance of reducing technical debt. Poor architecture, infrastructure, and code quality slow development and cause live site issues that crush morale and burn out teams. The longer these problems persist, the more they multiply on top of each other and the harder they are to fix. That’s why they’re called technical debt—the trouble they cause compounds.

However, even engineers who want to pay off technical debt have trouble doing so. While enlightened managers prioritize this valuable work, those leaders are rare. That’s because managers are expected to deliver more new work than their staff can produce. There’s no time, no resources, and no monetary reward for paying off technical debt. It just builds up until a catastrophic failure so embarrasses upper management that they demand the offending issues be resolved.

Back in the days of Waterfall, engineering teams would use planning periods to pay off technical debt while PMs and designers produced plans and specs (often called “Milestone Zero” or “Milestone Q”). In the present days of Agile and continuous delivery, there’s no time available. How do you pay off technical debt before a catastrophic failure? How do you convince management to invest the time? Glad you asked.

Ain’t gonna happen

Even if you manage to include time in your schedule for fixing architecture, infrastructure, or code quality issues, there’s a good chance that allocated time will get reduced or squeezed out entirely. That’s because reducing technical debt takes months of investment to pay off quietly in higher productivity and lower incidents (security, reliability, and/or performance). In contrast, feature work pays off loudly and immediately by achieving business goals and impressing customers, partners, and management.

Even when management forces teams to limit technical debt using dashboards that track quality metrics, engineers are only rewarded (or avoid being chastised) if they do the minimum necessary to stay green (or yellow) on these dashboards. And management will approve exceptions if doing so keeps critical feature work on schedule. The message from management is clear: If you want to be rewarded this review cycle, invest the bare minimum in reducing technical debt.

You’re a part of something

If all the pressure and rewards are tied to delivering new features, how do you pay off technical debt? You make feature work dependent on technical debt reduction, tying the two together under the banner of new features.

There’s some subtlety to selecting the technical debt to include in your feature work and documenting and tracking it in schedules. As a related example, consider when a new feature requires work on the front end and back end. Naturally, you associate all this work together in the schedule, typically as subitems below the new feature. (If you didn’t, you’d risk part of the work being delayed or discarded, destroying the feature.) In addition, you’d use descriptive names for the front-end and back-end work, clearly tying them to the new feature. (Otherwise, that critical work may be misunderstood or cut.)

The same rules apply when you tie technical debt reductions to new features. Don’t list technical debt work as separate, high-level items. Instead, list them as subitems below new features. In addition, use a descriptive name for each technical debt reduction that clearly ties it to the new feature. For example, if a new discounted bundling feature needs to be incorporated into a hairy mess of billing code, list “Refactor billing code to support bundling” as a subitem of “Discounted bundling.” If a new profile page requires deploying code and configuration changes together using your rat’s nest of a deployment system, list “Update deployment system to deliver profile page code and configuration together” as a subitem of “New profile page.”

While tying technical debt reduction to new features restricts the amount and kind of debt you can pay off at any given time, it does ensure that debt is reduced regularly and that the debt selected is relevant to current business priorities. That’s good for the team, your codebase, the business, and customers.

That’s just the way it is

Doubtful developers may say, “But what if management deprioritizes or discards the technical debt subitems?” Well, what would you say if management deprioritized or discarded the required back-end work for a new feature? You’d argue it was essential—that the new feature couldn’t be delivered without it. That’s what you say for technical debt subitems too.

“But what if management asks why the technical debt subitems are essential?” Tell them why the billing code needs to be refactored to support bundling and the deployment system needs to be updated to deliver profile page code and configuration together. If there isn’t a good reason, then save those improvements for a future feature that needs them.

“But what if I want to throw out a whole section of code and give it the rewrite it desperately needs?” If you can describe why that’s essential for a new feature, have at it. Otherwise, remember you are being paid to deliver value for the business and our customers. If there’s work you want to do that isn’t directly related to the business and its customers, you’ll have to do it on your own time.

It’s getting better all the time

High-performing teams keep their technical debt low to improve morale, productivity, and quality while minimizing incidents, rework, and drudgery. However, short-term incentives are all focused on producing more features. So, to keep technical debt low, associate reducing it with new feature development. When the changes to deliver a new feature require adjusting a poor architecture, updating problematic code, or improving an unreliable build and deployment system, list fixes for those areas as subitems of the new feature. Give those subitems names that clearly associate the improvements with the feature. If asked to defend those subitems, describe why the improvements are critical for the successful delivery of the feature. If you can’t defend the work, don’t include it.

Including technical debt reduction as subitems of new features makes debt reduction incremental, since you can’t do it all at once and still deliver new features in a timely manner. There may be times of crisis when management prioritizes focused debt reduction, which is great; otherwise, it’s bound to be incremental. Embrace that reality. Keep your debt low with constant improvement and vigilance. You’ll be happier, your team will be happier, and you’ll better serve your business and customers.