Ask HN: How do you explain tech debt (to non-techs)? Tech debt is often a taboo. Talking about it can be bad and arguing for addressing it can be worse. But I'm not sure everyone talks about "tech debt" in the same way. I've seen people use it as excuses for "time on what I want to do" and definitely seen management refuse it for that reason. But I've also seen management refuse addressing it to the detriment of the product/project. So what, actually, is it? And how do you explain it? |
It might be manageable for a day or two but very quickly you will suffer and probably give yourself food poisoning.
I speculate confusion about the term originally came from the word “debt”. For a layman it tends to be associated with an extremely narrow definition.
Metaphor that leaps to my mind: bakery thats in the bread business, but delivers product with trucks... not maintaining the truck fleet would be an equivalent to technical debt; when the trucks fail so does the business, even though the cause might be arguably unrelated with what they do as a business.
Another useful one is "capacity is like a dam, the load is like the lake behind it" and then talk about storms surges and boat wakes slopping water over the edge of it, starting erosion, and then everything falls down catastrophically.
Velocity = X*-1 + (everything else).
With enough technical debt, everything else won’t, or barely, overcome it. You won’t make headway.
You need technical PMs and technical Product devs (people that know how to turn a Figma into an app on their own, know how to make a simple rest api, etc) to even make the case, otherwise they will opt to just throw more people at it or new people at it. It’s a pointless battle, our industry is so big we employ many agile folks with about the same experience and skills as someone working at McDonalds.
Sorry kids.
Personally, I’d never even give a future recommendation to anyone that created that kind of tech debt on any codebase I’ve been on. I stay away from them professionally, it causes nightmares from top to bottom (from business, design, dev, qa). We don’t fire these people quick enough because the McDonals Agile folks love all the initial throughput.
I’m not sure who else to blame.
So, you go back and dig out those gotchas, and try something else, it takes some time to understand what went wrong, and how to make it better without creating new and even hungrier gotchas. This process is called refactoring, and in the end it saves far more time and effort than it takes, but it requires concentration and time to do a good job, so please respect the closed office door, or other flag that I can't be interrupted right now when I'm refactoring.
- Credit card debt (get instant gratification today but interest payments later will cost more than present benefits)
- Kitchens (everyone else just sees the nice food coming out but if you don't clean up the kitchen, pests/mold start accumulating and cause problems later)
Deployed [infra/code/apps] for which few people have remaining context within the company for how those items designs were come about, dated information, SPOF that cant be easily addressed (like a mission critical machine running in a closet that has one-sh job, but can never go offline with causing issues...
And, having to dedicate time/effort/staff/your-own-personal-time+angst to maintain dated systems in a way that may not be efficient for the team/company financially, but you're beholden to it as you determine how to allocate staff who would be better at doing something else, but they need to create projects to manage/update/replace
So, time it. Do it when things are going well overall. Educate, instead of preach.
You could do this as fast as possible without considering the costs… and by the end of it, maybe you realize now you can’t afford the specific hardwood floors or baseboards you wanted because you’re out of money. Or you decided to go with the expensive back splash in your kitchen, but now you’ll have to settle for cheaper windows that don’t sufficient block out road noise - impacting your quality of life when you can’t sleep at night.
Maybe you went with the lowest bidder for some of the electrical work, and now the electrical sockets are literally lose and the new TV you plugged in gets burned after you plug it into the outlet.
Tech debt is when you make decisions, often deliberately but sometimes without thinking through, that impact not just the house immediately when you move in, but also your ability to maintain and enjoy your new house afterwards.
We cut corners on the plumbing… man the septic system is now backed up and leaking out in the back yard. But we had to move into the house by a certain date and that was the main thing we optimized for over all else, and so here we are.
At this point, you’re thinking - well, all of this doesn’t sound THAT made. True.
Imagine that to fix the electrical problems, you now have to first remove all the cabinets from the kitchen and take apart the sink. Wait… that doesn’t make sense. How could it be that the kitchen sink and cabinets are so tightly coupled with the electrical system?
Now imagine that to fix the septic tank issue, you have to dig up the entire backyard and the garage. Yikes!
And for some reason, the plumbing in the bedroom is having additional problems. To fix it, we actually have to take down load bearing walls in the bathroom and the living room… while people continue to live in the house.
And that is tech debt. We were actually scheduling a party for next week. We can’t have the party now. Or if we do, maybe we can invite half the guests.
And sonny wanted to play drums. But the new windows are shit and don’t block noise. We bought a house so we wouldn’t have to worry about noise bother apartment neighbors, but with this construction, the neighbors are equally as likely to call cops and get the HOA on us.
The risk is: Once you need to hire for it, you won’t be able to find top talent to do it.