What Cars, Libraries, And Snowballs Have To Do With Prioritizing Technical Debt

If you’re a car owner, you know the feeling when a light appears on your dashboard.

Suddenly, there’s this unknown, scary problem you need to address. But this light is yellow, not red. So, do you really have to take care of the issue right now?

You keep driving and consider your options. The ride is still smooth, and you aren’t hearing any strange sounds. Plus, you have somewhere to be.

Ultimately, you decide to ignore the light.

Maybe another one doesn’t come on right away. Maybe a few days or even weeks pass. But eventually, it does. And this time, the light is red – ignoring the issue further could lead to your car breaking down entirely.

As an engineer and now an engineering manager (EM), you’ve likely experienced this same progression of events, choices, and consequences with technical debt.

It’s an issue that’s incredibly easy to let build up, especially when you’re working towards an important deadline. Developing new code is also exciting, while cleaning up old code often isn’t.

Plus, you have lots of other responsibilities to manage, and other managers and stakeholders are already resistant to prioritizing technical debt.

So, why should you?

1 - The snowball effect

There are plenty of kids (and maybe more than a few adults) who don’t like brushing their teeth every day. If you’re a parent, there were probably (or still are) times when you fought with your kids about this.

Convincing them to build good brushing habits is hard because nothing bad seems to happen if they skip brushing their teeth for a day. But something definitely will if they don’t for a year. Namely:

Bacteria builds up
Gums start to recede
Cavities appear
And more

You can deal with each of these issues on their own, but they exacerbate one another and make the overall situation worse. If you let this go on long enough, you’ll need to replace some of your kid’s teeth, maybe even all of them.

This is the snowball effect. And if you’ve never experienced it with technical debt, know that the effects are just as disastrous. In fact, letting the problem grow to that point pushes the debt beyond your team’s capacity to handle it. The amount of time, people, and money needed will simply be too much.

In the worst-case scenario, you’ll have to do a full rewrite. This is a total nightmare, and I’ve never seen one that was successful.

2 - The chaos effect

If you’ve ever used a library, you know the power of a sorting system. You can use it to find any book you need. There’s one section for American literature, another for European, and so on. Inside each are further divisions by century, genre, author, and more.

What’s important here is not the factors defining the organization but rather the system being understandable and consistent.

Now, imagine there’s a librarian who doesn’t put all the books back in their place right away. Maybe they’re the only one on duty, and they don’t have time for every needed task. Or maybe they take a shortcut to save some time and place loose books according to a system they keep in their head (or none at all).

If they were able to return to those books and place them properly, this probably wouldn’t turn into a major issue. But there’s a high chance they’ll never have time to do this. Or other complications might arise, such as them leaving and their replacement coming in with a completely different system (or, again, none at all).

Most people won’t notice the misplaced books at first. But if enough librarians fail to follow the library’s sorting methods, eventually locating them or even confirming if they’re in the building becomes nearly (if not entirely) impossible. At the very least, the work necessary to do so now vastly outweighs the success of actually finding them.

This is an important analogy for the issues caused when engineers don’t write code according to established structures so features can be integrated over time. When they create workarounds or take shortcuts, they inadvertently create more problems than they solve, including people struggling to navigate the code.

But it’s important to remember not to blame or accuse them when discussing all of this. As you well know, engineers have challenging jobs. And like the librarians, their reasons for not following protocol are often driven by necessity or a desire to help.

3 - The ripple effect

Speaking of books, imagine you’re a writer like J.R.R. Tolkien. After you’ve written a draft for The Lord of the Rings, working on it for years, you decide to make some changes. For example, Gandalf will use a wand instead of a staff.

This is a relatively simple change on the surface, but it does mean you need to go through over 1,000 pages of dense text to change all references to his staff. Otherwise, the wand will switch to a staff (and back) throughout.

But it’s more than just a word you’ll need to update.

For example, maybe there’s a scene where Gandalf originally used his staff to stop himself from falling off a cliff. But because the wand is shorter and more breakable, this scene no longer makes any sense.

Or maybe you’ve built important and complex lore around the staff, which you’ll need to adjust to fit it becoming a wand. Which also means you’ll need to make sure those changes don’t result in more necessary adjustments to other parts of the book.

Again, this is an important analogy for the issues technical debt causes. You’ve probably seen this happen before. But if not, the short version is that every change creates a ripple effect, necessitating other changes. Some you can predict – others you can’t.

It’s even possible to break the system. And sometimes, you won’t even know where to start looking for the culprit.

4 - The slowdown effect

Have you heard this argument against prioritizing technical debt? That it takes time away from making new products and features and slows the rate you release them?

On paper, the argument is a solid one because it is true that working on technical debt slows down new work. But it’s also true that the more you let technical debt build up, the more new work slows down.

For example, imagine streets are desperately in need of repairs. You and others use them for daily activities, including getting to work and home. You’re used to how long it takes, even with the mounting number of potholes and other hazards.

Instead of fixing those streets, the government focuses on building a new bridge or an additional highway. Necessary work, but those streets you and others use continue to worsen.

Eventually, they require major repairs they otherwise wouldn’t have. These problems divert necessary resources from other current and planned projects, slowing them down.

They also exponentially increase your and others’ driving time. Not to mention, you’ll have to use other roads that may be in need of repairs as well, adding further wear and tear to them.

With all this in mind, the argument from before should shift to saying everything slows new work down. But sometimes, the slowdown is necessary to avoid even worse ones.

5 - The turnover effect

As an engineer, how much did (or do) you enjoy working with problematic or debt-ridden code? If you’re like most engineers, the challenge was interesting for a while, but you much preferred handling clean code. And if you’re like some, you even considered or did eventually leave the team tasked with the first kind.

Legacy projects, as you may know, are especially prone to this problem. The longer a team has worked on a product, the more technical debt has likely accumulated along the way.

In my experience with legacy projects, I’ve even seen some engineers spend as much time on maintenance as they do building new features.

Also, in my experience (and perhaps yours as well), many engineers aren’t used to this division of work. The majority of them have spent more time in startups, so they’re more accustomed to fresh code.

And there’s another problem when you onboard new engineers.

They will implement a feature according to accepted best practices. Then, an older team member will take them aside and say, "The code is great, but it has to change because of this or that piece of technical debt."

This takes time and causes no small frustration. This can also eventually lead your new hires to realize they’d much rather find another team than learn how to use your bloated, increasingly complicated system. And you’ll have to find even more new hires to replace them, which starts the process all over again.

The short version: don’t wait, eliminate

It’s easy to not prioritize technical debt, especially as other managers won’t consider it an issue. But not addressing it in regular intervals means a growing problem that affects everything.

To be specific, not managing technical debt causes the following:

Worse issues to develop down the road
Difficulty navigating the architecture
Unexpected consequences elsewhere in the code
Slowdowns to new work
Higher turnover and onboarding issues

So, what can you do to prevent these and other problems?

In short, take ownership, advocate for dealing with what’s there now, create processes for managing it, and evaluate and adjust as needed. Your future self will thank you.