3 Sources of Tech Debt and How to Manage It

Software engineering isn’t a field known for glamour, but if there are glamorous parts, then technical debt certainly isn’t among them.

Technical debt is a term with many definitions and many disagreements between them. For this article, we’ll rely on the original definition from Ward Cunningham, which states that tech debt emerges from a disagreement between business needs and the software as it is actually written. From that foundational disagreement, he says, “We are going to continuously stumble … and that would slow us down like paying interest on a loan.”

In other words, technical debt is when the business as a whole and the software development team as a part do not align, and when that divergence causes the software development team to slow down over time. As time goes on, the team slows down further, until you can pay down the tech debt and/or refactor the codebase.

Tech debt, in these words, sounds bad. But it doesn’t have to be.

Imagine your dream home. You may be able to afford it in 30 years, but you want it today, so you go into debt. You get the benefit of a home today at the sacrifice of slowly paying off the debt for a few decades. That’s a rational decision many families make around the world, and it’s one software development teams make too.

The key, however, is making sure that when you decide to take on debt, you do so intentionally and with a plan to pay it off. If you don’t, you’ll have a foreclosed house or a rotten codebase. Below are three sources of tech debt, which you may or may not intentionally leverage, as well as ways to manage the tech debt that results.

1. Speed

Speed has a bad reputation. After “move fast and break things” went from inspiration to derision, the idea of intentionally moving fast often feels like a dangerous course of action. But for most startups, speed is a reality as well as a necessity.

Take Squarespace, for instance. When the company was around 600 people strong, the development team started working on Email Campaigns, its email marketing product. First priority was the email editor, but the team didn’t want to build a real email delivery infrastructure to support it, when what they really wanted feedback on was just the editor.

Instead, according to Jon Thornton, engineering manager at Squarespace, they built the “simplest, jankiest, quickest, thing we could” — a loop that took a list of email addresses and looped through them one by one, sending emails along the way.

Was it good? No. It would have fallen over the moment a customer used it to send an email campaign. But that wasn’t the point. It was good enough for Squarespace to use to send emails, which meant it was good enough for people to experience the editor and provide feedback.

According to Thornton, they spent about a week on this project, which he unashamedly called “throwaway work.” If anything, he said, the team actively looked forward to deleting the code.

Speed is worth embracing, as is the technical debt that results from it, as long as your team is aligned on eventually paying the debt down and the worth of the investment you’re making. Squarespace needed feedback before it needed a built-out infrastructure, so they prioritized speed while ensuring they had a plan to pay off the debt that speed created.

2. Time

Tech debt is inevitable because the march of time is inevitable. If only, however, we merely had to keep up with time. The ripple effects of Moore’s Law, especially as they collide with an industry fueled with venture capital, means that tech is always changing.

In a DevOps Days talk, Dave Stanke, developer relations engineer for Google Cloud Platform, pronounced that “all tech is debt.” According to Stanke, tech never stops moving: “A new framework, a new language, a new this, a new that. It’s baffling.” Tech debt results not only from that bafflement, but the sheer speed of technology.

“Whatever was the state of the world when you designed something, that’s old news by the time you’ve deployed it,” Stanke said. All tech is tech debt then, because time makes it debt by the time it’s reality.

Because Stanke believes “there’s nothing that you can build that’s not debt,” he argues that “your only hope is to get to what’s next as fast as possible.” That means investing in people and their domain expertise, the closest thing you have to a persistent asset and a defensible moat.

If tech debt is inevitable, and according to Stanke, it’s as inevitable as time, then investing in your team is the best way to ensure you avoid bankruptcy.

3. Disagreement

If we return to Cunningham’s original definition quoted above, you’ll notice neither speed nor time are highlighted. Instead, Cunningham focuses on disagreement, a focus Lenovo’s Luca Rossi also picks up on in this article for Refactoring.

Disagreement, here, refers to the difference between business needs and software development reality.

Here are three disagreements that might incentivize the accumulation of tech debt:

1. Business leaders are looking for an exit. If the company’s executives are focused on an exit, especially an acquisition, they may want to take on tech debt to acquire users and revenue, such that they can entice acquisition offers. They may prioritize growth over tech debt and leave the payment plan for a post-acquisition effort. Ensure that business leaders and engineers are aligned, such that business leaders learn to prioritize tech debt for the long term or engineers learn to take on tech debt for the short term.
2. Product managers are overly ambitious. Product managers, sometimes incentivized by higher-ups, may set a product roadmap that unintentionally requires engineers to take shortcuts to make sprints. Tech debt will accumulate as engineers prioritize completion of features over the sustainability and maintainability of those features. Product managers can prioritize tech debt by creating a closer feedback loop between them and the engineers they’re working with. On-the-ground engineers are in the best place to know whether a feature will be landed in time with or without sacrifice.
3. Project managers don’t make time for tech debt. Your team might agree that tech debt is worth addressing, but if your project schedule doesn’t account for it, then it might never get done. Prioritize tech debt by pairing tech debt with high-impact projects (see adviser Gergely Orosz’s argument for this method here), dedicate the last few cycles of each quarter to tech debt (see Dropbox’s Leemay Nassery’s argument for this method here), or designate one day out of every sprint to work on tech debt (see Squarespace’s Thornton’s argument for this method here).

Disagreement is perhaps the hardest source of tech debt to manage. The solution — or solutions, really, since every solution will have to be tailor-fit to every context — relies on people, not technology.

Tech Debt is Inevitable But Your Payment Plan Isn’t

The title of this article was chosen deliberately; tech debt isn’t something you can eliminate, contain or escape, but it is something you can manage.

Speed is a business necessity; time is inevitable and inescapable; and disagreement is unavoidable. Your goal, then, isn’t to avoid tech debt, but to identify its sources (this list is not exhaustive!) and think through plans of managing each type of tech debt as it emerges and as it accumulates.

Remember, tech debt isn’t necessarily a burden. It’s a powerful lever you can choose to pull, but one you should only pull if you have a payment plan in mind.