What is the common thread among tech debt-crippled companies you've worked in? Not enough man hours to pay it down, difficulty to align engineering's willingness to pay it down with product's focus on new features, or something else? How can it be that, in the age of AI code gen, we haven't yet managed to solve this once and for all?
Most of the tech debt I deal with comes from projects that are declared a success by management before they are actually done, and no one is officially responsible for maintaining it. The teams are told to move on to something new, the old thing never gets fully finished and dies a long slow death, because no one wants to officially say that it was a waste of time and should be shut down.
Do this repeatedly and it really starts to add up. At times we are running 3-4 platforms for the same thing. Two are legacy with one or two critical things still running on them with no support. One is “production”, but no one is actually paying much attention to it. And one is in development or pilot… it’s all anyone can talk about, but it doesn’t actually work. While that in-house developed pilot is going on, we’ll also be told to do a POC with a tool from some outside vendors.
AI won’t solve political and bureaucratic problems. If anything, it will make it worse, as turnover to new products is expected faster.
To get rid of technical debt, an organization needs to focus. Which means saying “no” to most things, instead of trying to do it all.
AI makes technical debt so much worse. Speaking from the frontend perspective- reducing technical debt is all about making changeable standardized code. However models change structure, variables names, or changing variables means I'm building a lot of frontend on a shaky foundation. I routinely spend hours a week just fixing weird frontend builds. And as I'm the frontend role, my cofounder doesn't understand design, so I often get messy code
A lot of tech debt I've seen stems from people tacking things onto a loose foundation – adding API endpoints when there's no clear pattern, adding validation or defaults in different ways, organizing layers of code in various ways, multiple implementations of the same business need.
This is compounded when people come and go. The software/tech industry, in my experience, does not encourage long tenure – layoffs, reorgs, and the general trend of people hopping between employers every 2-3 years.
Startups also love the idea of building things fast and ugly, and 5 years later that leaves the company with a successful product (hopefully), a team that's grown fast (and turned over multiple times), and a shaky foundation.
Engineering generally seems open to paying down tech debt, but there's an overwhelming amount of it sometimes, and someone needs to deeply understand the problem and lay out a clear plan for taking care of it, and that takes serious effort.
If you have one person who owns an area/domain it tends to stay pretty clean.
But as soon as you add more people it becomes patchwork
Do this repeatedly and it really starts to add up. At times we are running 3-4 platforms for the same thing. Two are legacy with one or two critical things still running on them with no support. One is “production”, but no one is actually paying much attention to it. And one is in development or pilot… it’s all anyone can talk about, but it doesn’t actually work. While that in-house developed pilot is going on, we’ll also be told to do a POC with a tool from some outside vendors.
AI won’t solve political and bureaucratic problems. If anything, it will make it worse, as turnover to new products is expected faster.
To get rid of technical debt, an organization needs to focus. Which means saying “no” to most things, instead of trying to do it all.
This is compounded when people come and go. The software/tech industry, in my experience, does not encourage long tenure – layoffs, reorgs, and the general trend of people hopping between employers every 2-3 years.
Startups also love the idea of building things fast and ugly, and 5 years later that leaves the company with a successful product (hopefully), a team that's grown fast (and turned over multiple times), and a shaky foundation.
Engineering generally seems open to paying down tech debt, but there's an overwhelming amount of it sometimes, and someone needs to deeply understand the problem and lay out a clear plan for taking care of it, and that takes serious effort.