Why you should consider technical debt to be real debt

Jan 18, 2017 | Leadership, Productivity

Imagine your CFO walks into your office with a pained look on her face.

She announces, “I just ran some reports and I’m concerned. We need to tighten up spending over the next 2 quarters so that we can pay down our line of credit, or else we’re going to be in real trouble a year from now.”

This would probably get your attention.

Yet when CTOs makes a similar statement, (e.g. “I need 50% of my staff to focus on paying down technical debt”), it tends to be treated as a nice-to-have based on engineering preference.

The reason is pretty simple: Execs and staff outside of engineering cannot see the ROI, and the gains do not fit into a tidy quarterly window. Which means recommendations like these are continually sidelined in favor of the next headline business goal.

Paying off debt is, after all, not very sexy.

Sure, technical debt makes sense as an abstract concept. But rarely do business stakeholders think of it as actual debt, instead thinking of it as the “still-ineffable reason that engineering deliverables are late (again).”

This thinking is a real disservice to our industry. And, ironically, is quite toxic to sustained innovation.

Accruing real interest

The use of the word “debt” is actually quite brilliant because technical debt behaves very much like financial debt. Consider:

  • Technical debt is often created by engineering teams rushing to meet today’s deadline at the expense of future efforts and technical quality.
  • Paying off debt requires discipline, and making due with less—getting by with a thinner stream of new features while debt is cleaned up.
  • Left unchecked, tech debt snowballs like compound interest. All engineering activity becomes incrementally more expensive as tech debt grows.

Accruing technical debt makes perfect sense for young startups.

The thinking goes: pay for today’s progress with tomorrow’s efforts, until it’s clear whether the company will survive in the market.

It’s simple economics. Since most startups fail, there’s something like a 90% chance the company will simply fail and the debt will never need to be paid.

As it turns out, this reasoning has a pretty short shelf life.

What senior management hears is “engineering is requesting permission to move at half pace for the next 3 months.”

Once a company has achieved the lauded “product-market fit” and is off to the races, it’s no longer a great idea to just stack debt on top of debt. But habits from the early days are hard to break.

Companies in the early growth stage are still fragile, finances are still tight, and customer expectations are increasing. And all debts eventually come due.

The real problem with accruing technical debt is that the business will never want to pay it off. Since the pain of technical debt is often felt by engineering alone, paying it off is a very difficult thing to rally stakeholder support for.

What senior management hears is “engineering is requesting permission to move at half pace for the next 3 months.”

The rest of the company has trouble relating to the abstract nature of engineering work, and tech debt all the more so. No wonder requests to paying tech debt down are so easily brushed aside.

The tech debt death spiral

It’s common to encourage startups not to worry too much about technical debt in the early days.

But startups are not forever young.

While technical debt may not kill early startups, it absolutely does kill companies in the growth stage. It just doesn’t happen with the fireworks of other kinds of failure. Death-by-tech-debt is a slow, lingering kind of death.

Here’s what the death spiral looks like:

  1. The company sidelines engineering’s concerns as a nice-to-have
  2. The codebase itself quite literally becomes a “difficult work environment.”
  3. It gets hard to recruit strong engineering talent.
  4. The company’s best engineers start to leave for blue-sky work at other startups where the codebase is more enjoyable to work in.
  5. New features start shipping very slowly. Or stop altogether.
  6. Gradual attrition of all engineers who like building things until only “maintenance-style” engineers remain.
  7. Company falls irrecoverably behind the times.

If you accrue technical debt without budgeting time and resources to pay it off, parts of the codebase become too unmanageable to modify. Engineering deliverables get smaller and less frequent.

Gradually customers experience the zombification of your product.

Eventually the codebase goes bankrupt. And the only practical choice will be to rebuild the entire thing from the ground up—something which very few businesses ever get a chance to do.

Death-by-tech-debt is a slow, lingering kind of death.

Incremental payment of technical debt is better, much like slowly paying off a line of credit. It’s something that can be consciously incorporated into engineering operations while also investing in new work.

But engineering teams need buy-in from management to do this well.

If your engineers have been doing heroic things for the past year or so, chances are they’re selling a bit of the future to do it. This is normal. But be prepared for the bill to come due.

When your engineering team talks about technical debt, listen. Listen like you would listen to the finance team talking about financial debt.

The future of your product could very well depend on it.

 


 

Travis Kimmel

Travis Kimmel

Travis Kimmel is the CEO, co-founder of GitPrime, the leader in data-driven productivity reporting for software engineering teams. He is experienced in building high-performing teams, and empowering people to do their best work of their careers. Follow @traviskimmel on Twitter.

Get Engineering Impact: the weekly newsletter for managers of software teams

Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.

how to use data to lead a successful software teams

A Data Driven Approach To Leading Software Teams

Learn how engineering leaders are using data to help their team increase productivity and become even more effective. We've analyzed over 40 Million commits to help you understand the important questions every software engineering manager needs to know.

Success! Please check your email for your download. You might also be interested in Engineering Impact: the Weekly Newsletter for Managers of Software Teams. Keep current with trends in engineering leadership, productivity, culture and scaling development teams.

Share This