Ask HN: How do you explain tech debt (to non-techs)?

...continuing to cook meal after meal in the same kitchen, but never cleaning up, or washing a pot or pan.

It might be manageable for a day or two but very quickly you will suffer and probably give yourself food poisoning.

Tech debt is lack of infrastructure maintenance.

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.

"It's like we've swept so much shit under the rug - it's getting hard to walk around the room without breaking anything."

X = technical debt

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.

When solving a problem with a computer, there are any number of ways to do it, and it's not clear until later if any given approach has a "gotcha" that works strongly against it until after the fact. Over time, you're throwing more and more computer time, and programmer time, into feeding those gotchas.

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.

I've heard tech debt compared to:

- 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)

Imagine not having a waste management system: you'll end up with garbage everywhere. Hence, you need to invest time to do garbage collection (and perhaps permanently solve the problem by introducing garbage bins, garbage trucks, etc.). You can take the metaphor further :)

For me, technical debt is two things:

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

When you hardcode something because parameterizing it would take you five times as long. My advice is learn to code so your corporate existence isn't just tire-spinning semanticising.

I would say it is more about "when" than "how". If the market need is to get features out to survive and win enough customers, you are not going to see a lot of success trying to explain technical debt to non-techs especially decision makers. If things are hunky dory, you may have an opportunity to explain.

So, time it. Do it when things are going well overall. Educate, instead of preach.

Imagine you’re building a home. Maybe you have the time and experience to build the house yourself, but many parts of this project will be handed off to people who specialize… in designing the structure and floor plan, in laying the foundation, setting up the walls, laying electrical, plumbing, HVAC, and so on.

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.

Executives may or may not understand “paying down” tech debt. Creating yet another metaphor: it’s easy to understand why dental work is delayed until the off-season.

The risk is: Once you need to hire for it, you won’t be able to find top talent to do it.

If they know even a little about cars, perhaps a tire age/dry rot/blowout analogy would work best.

"we cannot release until this chunk of code getting refactored "