Technical Debt Can Wait

We’ll fix it later

Deadlines are looming, so the team goes with a quick fix. After the release, we add a task to the backlog and promptly forget about it. Six months later, half the product relies on this hack and nobody wants to touch it. Technical debt builds up through rushed work, architectural compromises, outdated dependencies and missing tests. Sometimes we knowingly trade implementation quality for a deadline.

The trouble starts when temporary fixes become permanent and nobody accounts for the consequences. Old code isn’t automatically technical debt, though. A developer wanting to rewrite everything doesn’t mean the project needs refactoring.

Where technical debt gets in the way

It starts with developers complaining about the old code. Estimates creep up, small changes need extra checks and touching one module breaks the next. Eventually, the team will spend more time working around limitations than building features.

The PM doesn’t need to understand every line of code. We look at recurring bugs, effort, dependencies and release issues with the tech lead. If the same limitation keeps affecting estimates and deadlines, it’s time to work out what it costs the project.

What does technical debt cost?

Say refactoring a module is estimated at 24 hours, or three working days. Each new feature also takes 24 hours. Accumulated technical debt adds another eight hours to every feature. That’s an extra day each time, and there are ten more of these tasks in the backlog.

Refactoring breaks even after three features, provided it removes that extra effort. The client sees it differently. In those same 24 hours, the team could build another feature they actually need. Instead, we’re asking for three days of work with nothing they can show users or management. Why should they pay for it?

First, we check the estimates with the tech lead and look at what’s coming up in the backlog. If the module only needs one more change, refactoring might cost more than living with the limitation. If we keep developing it, putting off technical debt starts eating the budget.

Who pays for it?

In client delivery, the feature set and budget have already been agreed. Now the team wants extra hours for refactoring. To the client, it looks like we’re asking them to pay for fixing our own work. Sometimes they have a point.

We need to look at where the debt came from. Was the technical compromise discussed and agreed with the client upfront? Or did the team pick a quick fix on its own and now expect the client to cover the fallout? Requirements can change too, leaving the original architecture unsuitable. In each case, we review the agreements, the reasons for the debt and whether the work is necessary.

The PM shouldn’t promise a free rework or send a refactoring invoice on their own. First, we discuss the need and the estimate with the team. Then we check the contractual obligations and get internal approval for the costs. After that, we decide what to propose to the client and on what terms.

How to get it into the Sprint

Technical tasks keep losing out to new features. The client wants something users can see, while engineering wants three days for refactoring. “We need to tidy up the code” impresses absolutely nobody. So we work with the team to show how the debt affects upcoming tasks: extra hours, bugs and release risks.

If 24 hours of refactoring can save 80 hours across the next ten features, now we have a bloody good argument. We agree on the smallest useful scope of technical work, revisit priorities and decide what goes into the Sprint and what has to move.

We can reserve some team capacity for technical debt or tackle it while making changes to the affected module. Those hours need to be in the plan. Otherwise, the technical task gets pushed to the next Sprint again and the team keeps spending time on workarounds. Until another “temporary” fix becomes too expensive to touch.

Or we can keep adding the task to the draft plan for every Sprint at low priority, leaving it out of the agreed scope until it’s approved. Maybe the client will eventually give in and sign off on the damn refactoring.

About the author

Anya Kargina

I’m a project manager. About working with russian clients and teams, sharing experience and things I’ve noticed.

Back to the top