[ahdh8f4hf4h8]

Personally, I no longer use the phrase "technical debt" when speaking to management. It's just too vague of a term. Instead I just explain the actual problem and the consequences - too much near duplicate code leading to slow maintenance, non-scalable design choices leading to slow processes, rigid design choices which hamper the team from implementing the upcoming stories, excessive complexity leading making the code hard to change.

Once you get our of analogies and into actual problems, then you can have a reasonable discussion about future tradeoffs. I find even with non-technical managers, debt/wealth is just not a good analogy for code.

Also, often poor code is just part of a larger process problem. You really need to optimize for the whole project, not just code-level to improve the situation.

[redroot]

I've also found the term quite dangerously misleading. The 'tech' part of the statement makes it sound like the 'debt' that is getting in your way it's purely a concern of the engineering function, where it should be a concern of the business. The 'debt' part is also confusing - I have seen non-technical stakeholders thinking it can be dealt with like financial debt with more revenue or VC rounds in one lump sum, we don't have to worry about it because are a growing startup and debt is normal.

Two alternative explanations I've begin to use over the last few years that have helped:

1) Inertia / Inert Areas - the reason this 'debt' is a problem is it means future changes are hard to execute cleanly, and previously. An area becomes inert to change unless an intervention is made. For non-technical stakeholders they most important thing is often that we can keep making changes, so this sets all sorts of loss aversion alarm bells ringing in a way the term 'debt' doesn't - this is where you can start talking about risk, which crosses the divide between engineering and other functions quite well.

2) Product Debt - Yes in some cases code is just badly written, which is an engineering concern, but often the reason changes in Year 5 are hard to make because the domain / reality has moved on, and the assumptions baked into the code written in Year 2, no matter how clean the code, are now just wrong. For example, baked-in assumptions of how business works in Market A as you are expanding into Market's B and C. This isn't the fault of engineering, just the reality of a product that continues to persist - core changes are inevitable. Product leaders therefore need to also get strategic about when it makes sense to rethink previous decisions driven by product needs, and work with engineering leaders to mitigate otherwise you might end up in an inert ball of mud unable to hit goals.

In the most idealised vision of a piece of software, changes will get harder to make in a linear fashion if previous decision are not revisited will new information. In worst case it's more like an exponential graph, so intervention steps will always have to be taken.

As you say, once you're talking the same language, then you get into the details about what strategies to address this inertia / current conditions.

[lowercased]

> For example, baked-in assumptions of how business works in Market A as you are expanding into Market's B and C. This isn't the fault of engineering

And you can bet the farm that some dev (or team) was trying to build in some flexibility in to the models which might have added an extra 2 weeks to deliver, which would save months of re-development a year later, and was shot down with 'YAGNI!' or just... "we don't have time!"

For some reason "management" folks get to plan out for the next 4-8-12 quarters, but a dev putting in basic plumbing to accommodate change that will happen 6-12 months down the road is simply rebuffed. "Oh, developers just want to write stuff all the time, they don't understand business", etc, and other nuggets I've heard over the years - grates me to no end.

[secondaryacct]

Yes I agree. We get sometimes trapped in fixing well working but awkwardly written features, when the very well written initial assumptions just slow any change much much more visibly, which could actually be fixed by ... a badly written rushed silly code and multiply dev productivity.

So in a way the beauty of the implementation matter a lot less than its ability to change quickly which sounds obvious said like that.

[brightball]

Agreed. I like to use opportunity cost to try to frame the trade offs in terms of future developer time that will have to be used to address the trade offs which won’t be focused on other development efforts.

[pydry]

I've tried doing this. Their eyes tend to glaze over. They don't really care about the nitty gritty of the code nor should they have to.

[gridspy]

Then explain it in terms of the benefit. "I noticed it was hard to add features like <xyz> and I'm going to make it much faster, easier and more reliable for next time"

[pydry]

It doesnt really help much saying that it should do these things if you can't say how much and in practice I find you rarely can.

"How much faster?"

"Dunno"

Plus, at least half of tech debt is about risk not time spent which is even harder to quantify.

For the kind of tech debt you are describing (e.g. making adding a 4th payment system easier) it makes much more sense to wait until it is needed again and to just do it (this offsets the risk of it never being needed at all).

[dgb23]

It’s a matter of keeping your work environment clean and orderly and to separate different parts into different areas.