Imagine two people buying homes.
The first buys a brand-new one. Everything is ready for them to move in, and all they have to do is unpack.
The second buys a used one. Maybe they want to fix and flip it, or maybe they’re looking for a long-term family home. In either case, fixes are necessary. In neither case will they complain about it (ideally, anyway).
Even if they do complain, the house isn’t a disaster just because it needs a bit of work – any home standing more than five to ten years needs some maintenance. That’s just the way they are.
But people look at a product around three or four years old with some technical debt and think it is. Maybe even you do.
However, technical debt is just as inevitable as a house’s wear and tear, and that’s okay. Here’s why.
It’s a sign of success
There will be some engineering managers (EMs) who read this and think, “That’s not true. I’ve worked on plenty of projects that didn’t have technical debt. It’s not inevitable at all.”
If that’s you, I’d ask one question: what kinds of projects do you normally work on?
Technical debt is absent 95% of the time because a project is in its early stages. It’s the same with a home: renovations aren’t necessary right away because everything is still new. There hasn’t been enough time for issues to build up.
I once had a project where we only started thinking about technical debt five years in. We were a startup and lucky to have survived long enough to get to the point of looking for it. We found our:
- Market niche
- Buyers
- All of that
And like many others who passed that threshold, we also had time, specifically to think about addressing technical debt.
The fact technical debt exists isn’t a sign of failure – it’s the opposite.
We survived – this is cause for celebration. And the fact we can now look for and think about technical debt is a testament to our longevity. Not everyone lasts long enough to accrue it, which is sad but true.
So, I reject the idea of treating technical debt as a sign we’ve done something wrong. It’s not.
You’ll only ever have enough resources to mitigate it
Imagine you’re the village fisherperson. You live by the sea and if you want to survive, you have to take your boat out every day and bring back fish.
But there’s a catch: your boat has worn down and has holes. You don’t have enough money to buy a better boat, and if you spend the time needed to fix up the holes for good, you won’t be able to fish. You and your village will starve.
So, you think of a system. When you go out to sea, you bring people who bail the water out of the boat while you fish. You might also bring someone who can fix holes temporarily so the person bailing the water can get a head start.
It looks ridiculous, but this is your only way to feed the village.
Similarly, just by doing your work with software, you’re creating problems. And taking the time to address these problems significantly reduces your availability to create the features and products keeping you in business.
You know you can’t stop this cycle. So instead, you address the issues with:
- Workarounds
- Additional systems
- And people assigned to the work
This isn’t a bad thing – it’s just the reality of a long-term project.
It’s not you
Blaming yourself for the mere existence of technical debt is just as bad as blaming your engineers.
When I started as an EM, I’d already worked with systems for many years. So, I knew this.
But I work with a lot of new EMs (and even senior engineers) who get frustrated because they think they’re somehow the problem. They think if they managed the team better, there wouldn’t be any technical debt.
This is wrong and sends people down an unhelpful path. They’ll stress out over not having the resources they need or get frustrated at the engineers producing the debt.
They’ll be like a hero fighting a hydra: cutting off one head leads to three emerging in its place. It’s enough to drive someone crazy or burn them out. I experienced this first-hand myself.
What’s more, things outside your control dictate at least some of the amount of technical debt you have. For instance, maybe the company pivots in its early years, rendering whole sections of your code redundant. Things that used to be functional are now basically technical debt.
This is not your fault (nor your engineers’).
This is only a problem if we expect perfect code, though. But we’re not in the business of perfection – we’re in the business of balance.
Your job isn’t to make sure everything gets done – it’s to make sure the most important things get done. So, prioritization skills matter more than working yourself into the ground for impossible goals over unnecessary guilt.
Yes, this really is okay
I imagine a manager who isn’t used to technical debt would say, “How are you so calm? How can this all be okay?”
In answer, I would ask that manager whether they’ve ever lived in Morocco or Egypt. If they hadn’t, I’d explain that it’s:
- Hot
- Dry
- And the sun will kill you if you’re outside at the wrong time
Is that okay? It sounds like a silly question because this is simply the nature of the weather.
To survive, some people leave for other climates (if they have the money and paperwork). Those who stay wear clothes that match the location and stay cool however they can.
In short, they adapt.
You already do the same every day, especially in our industry. Writing more code produces more problems – that’s just how it is. And like the people living in Morocco or Egypt (or similar places), you can leave or adapt.
But the one thing you can’t do is change the weather.
So, if you’re still struggling with the idea of technical debt being normal and okay, it’s time to accept the reality of your situation.
And yes, it’s also possible to stop worrying about it
A number of cultures and spiritual traditions focus on acceptance. A friend told me that Japanese culture has a high acceptance of death, possibly because the islands constantly experience:
- Typhoons
- Earthquakes
- Tsunamis
- And other disasters
Their culture adapted and prepared people for these possibilities and what may come of them. In the same way, you can introduce a culture and practices to manage technical debt so it never overwhelms you or your team.
For example, you can:
- Constantly secure resources to deal with it
- Factor into the production schedule that every new feature will increase technical debt
- Dedicate a team to refactoring or get people to do it on a rotating basis
- And attract smart and diligent people willing to take on these tasks
Much like the yin and yang, you have engineers who make new stuff and engineers who keep everything in balance. You’re never going to fix things entirely, but you can reduce entropy and make sure you’re still moving forward.
The short version: this is one debt that’s okay to have
If you’re not used to working on a large or long-term project, you might not think that technical debt is inevitable. You may even blame yourself or your engineers for accumulating it.
Don’t. You’ll only make dealing with the issue harder.
Instead, to properly manage technical debt, do the following:
- View it as a sign of success: it shows that your company survived long enough to accumulate it, and that’s cause for celebration
- Know that you’ll only ever have enough resources to mitigate it: you need to make new things to keep your company afloat, even as you allocate people to the problem
- Know that you’re not the problem: managers and engineers aren’t at fault for technical debt – as long as you’re getting the most important things done, you’re doing your job
- Also, know that this is all very normal: technical debt is as inevitable as the weather – all you have to do is learn how to dress for it
- And stop worrying about it: direct your energy instead to building practices that make sure technical debt never overwhelms your team
Technical debt only becomes a problem when it snowballs out of control. With the proper practices, you can manage it and make sure it doesn’t become an issue. But this requires you to understand that technical debt is okay in the first place (because it is).
Want more tips on leading effective software engineering teams?
Join my newsletter if you’ve found this content useful
Originally published on Medium.com
Content in this blog post by Alex Ponomarev is licensed under CC BY 4.0.
