[pydry]

This is a common theme but I don't believe it's true. It mirrors all of those twee blog posts that come up with Yet Another Metaphor for technical debt as if people with MBAs would then just "get it".

It's not really about finding the right metaphor it's about lacking a common, shared unit of account.

Risks can't really be factored into decision-making unless you can measure them. Theyre not risks otherwise theyre just black swans waiting to happen (or not).

Technical debt and code coverage "as risks" cant be factored in either. Instead of trying to cargo cult the way "the business" talks or coming up with yet another metaphor we should be coming up with better ways to measure these things so that they can be plugged into an excel spreadsheet.

This is done incredibly badly right now. Most measurable code metrics which proxy things we care about are downright terrible at proxying them (e.g. test coverage). In place of working metrics most businesses (in my experience at least) rely on guesswork and trust in high level executives.

[35fbe7d3d5b9]

> Technical debt and code coverage "as risks" cant be factored in either.

They can be measured. Lots of companies don't, which is mind-boggling.

When a release goes sideways and has to be rolled back, you figure out why. Ah, you launched a feature that revealed an intersection of edge cases in your testing? That's n developers * m hours * p dollars of blended dev salary down the drain.

When your feature delivery slows to a crawl over time, you dig in – your programmers aren't getting worse over time... are they? No, you find that a ticket that took your average developer x hours to deliver at the beginning of your development now takes 2x or 3x. Make a value stream map and you'll find out that your test suite has become so sluggish that your developers can't iterate quickly, that QA now measures regression time in days not hours, and as a result your developers are taking on less work to compensate. X dev hours * Y blended rate in ongoing waste, plus factor in the value of missed sales because of missed features if you want to really put a point on it.

> It's not really about finding the right metaphor it's about lacking a common, shared unit of account.

Name the local currency you get paid in – dollars, Euros, pesos. That is the shared unit of account. If you don't care about it, start walking up the org chart. You won't have to go far before you realize that's what actually matters, and that engineers who can translate technical risks and inefficiencies in their world to dollar values are highly valued.

[thrower123]

People get mad when you start counting up how much salary the hours of meetings about why you aren't moving faster chews up.

That daily status meeting that pulls in twelve people for an hour to hem and haw about nothing? That costs $600 every day. $30k a year.

[SketchySeaBeast]

Only $600 for a dozen people? That's only about three people based upon the billable rates I'm familiar with.

[pydry]

>Name the local currency you get paid in – dollars, Euros, pesos. That is the shared unit of account.

Good luck trying to accurately measure technical debt in dollars.

[35fbe7d3d5b9]

Accurately is the hard part, but you don't have to be perfect here – just as accurate as next year's sales forecast is.

"I can't outrun a bear, I just have to outrun you" ;)

[SketchySeaBeast]

To take the metaphor, mangle it, and run with it - The problem is that technical debt isn't being chased by a bear, it's walking through the woods in bear country. It only becomes truly quantifiable when the bear charges you. Until then it's a "could be a problem". We probably don't even know the exact details of what sort of bear is going to come maul us, so it's hard to say "if we don't stop this a brown bear is going to come out and get us".

[35fbe7d3d5b9]

I don't disagree, which is why my original post talked about pricing technical debt retrospectively. You don't know when the bear will charge tomorrow, but past bear charges can be highly instructive if you learn from them.

My prod ETL process is an unloved mess, and we've had enough maulings occur to learn from it:

* I learned the problem – data models drift in the production app and changes aren't reflected / properly tested in the ETL or the analytics environment. And we don't have enough monitoring in place to catch the problem when it happens in the wild.

* I learned the cost of inaction – my analytics environment is responsible for $10mm of CARR, and I know the impact to customers when it goes down. Heck, I know how much customer credit has been given out due to SLA breaches, so there's a quantifiable price today.

* I learned the price to fix it - we've estimated the effort and run cost of the new solution.

Now I've got something that I can work with: customer acquisition says they've got $4m in the near-term pipeline? OK, great, but if we onboard them with a broken system we risk spending $+x in customer credits and risk damaging our reputation. And since it costs $y to fix it, and $x > $y, let's fix it.

I have plenty of other unloved systems that are in bear country but haven't mauled me (yet), but even then you can start thinking about risks. One system is small but critical for multiple products, so my exposure is "hey every single customer is getting service credits" – expensive enough to force the monitoring/refactoring work that it always needed. One of them serves logins for ~7k users but only for one customer so my financial exposure is bounded. We don't worry about bear spray when walking around there ;)

[majormajor]

I've never really seen tech debt cause an immediate, hugely-costly single event where you could say "see, that was the risk we were taking."

I've seen it frequently slow feature development down, though.

But... I've also seen a lot of rewrites fail to improve feature development speed.

So until we, as a discipline, can quantify and predict development speed w.r.t. shitty vs good code, it's going to be a tough conversation that'll rely on persuasion and gut estimates.

We normally can't even predict how expensive (time-consuming) doing that rewrite that we want to do would be! Let alone the benefit!