Technical debt and its costs are extremely hard to quantify and saying things like "with 3-6 weeks of engineering time we can cut failures in half" is just inventing numbers to get what you want.
I had a conversation that stuck with me a few years ago at a very large company about making proposals for future projects. I had a habit of making very detailed proposals, doing a great job making projections and being accurate about those projections.
A VP of engineering pulled me aside after he saw that one of my proposals wasn’t getting traction and told me “None of the people who are writing alternatives to your proposal are doing the analysis you are, that’s why they look better than yours”
I guess I had never considered that a lot of my peers were just inventing numbers to justify things they wanted and that there’s a careful balance that needs to be struck between “making shit up” and “detailed unbiased analysis”
That's when you suggest that the historical accuracy of the proposals should be weighed to determine the degree of certainty in future proposals from various sources, right?
Let's say person A gives longer estimates but is accurate within 10% more than 95% of the time. Let's say person B gives estimates half as long, but the team runs over by 75% a quarter of the time and by 150% about half the time. Whose proposals should the stakeholders choose?
If your company is making decisions based on estimates, the accuracy trend on those estimates is a far more important metric than lines of code, number of commits, story points, or nearly any other metric they're keeping.
You'd need to be very strategic in how you point that stuff out. Because straight up saying that numbers from those people have been consistently wrong throws the people bringing them forth under the bus and it will make the people who you're giving the proposals to feel like you're telling them that they are doing a bad job at evaluating proposals given that they did give the final approval on all of them.
You're probably better off just playing the game and making up good sounding numbers. You're less likely to have half the company resenting you and making your life difficult.
It's extremely hard to quantify the impact of any changes to a system so "inventing numbers to get what you want" is required whenever stakeholders are obsessed with predictability and quantification.
I get that a lot of people in IT are very facts-focused, but if you want to actually convince people that they need to act in some fashion, you need to add some emotional weight to your arguments (pulling numbers out of your ass is one way of doing that).
Admit it or not, the reason you want the technical debt addressed is primarily emotional. You are frustrated with how difficult it is to work, you fear for the future of the project. If you want to compel someone in charge to make changes, you need to make them feel things are bad as well.
This is to be used responsibly, though. If it turns out you've convinced someone into acting in a way that is against their interest or a big waste of time, there will probably be blowback later.
Fear of project failure is the signal that the company (= your employment prospects) will be damaged. Frustration with how difficult the work is, is a signal that the current path is unsustainable, and that burnout will set in, thereby damaging your ability to work (= your employment prospects).
It's perfectly rational to be concerned about these things. We are not machines - or rather, we are machines that have mental/psychological/monetary needs that have to be met in the course of our daily employment.
There is no purely logical reason to ever actually do anything. It all starts with what you want and what you don't want. You may of course derive logically sound paths to get what you want or avoid what you don't want, but that's something else.
If you explain these logical steps to someone else, what you're doing is showing them that they too will likely be affected by what you're suffering, that is, showing them they have a reason to fear too.
We are getting into the weeds here. Unless you are trying to tell me that there is no logical reason to trying to meet the bottom few tiers of Maslow's Hierarchy of Needs, in which case, while you may be right in a very strict sense ("nothing and nobody matters"), it's an extremely nit-picking position.
A message's ability to provoke some form of action is entirely dependent on its ability to create some form of emotion, be it fear and indignation or hope and optimism. The most effective rhetoricians are exactly those that are very good at producing those feelings. From Hitler on one side as the archetypal rabble-rouser; to MLK on the other end of the spectrum, who created profound optimism and hope. It isn't because of their syllogisms that they were convincing rhetoricians.
Merely knowing a fact is rarely sufficient to provoke action, unless that knowledge itself creates an emotion (an idea can have aesthetic value, for example).
I find I have to head check myself from having negative thoughts about approaches that I wouldn't have taken. Like seeing old java, or bootstrap :P. It still works, fixing it may make things neater, but does that really pay down debt?
Yeah, this feeling is ubiquitous among programmers (or 'developers' perhaps), and I suspect it's a large reason why businesspeople are suspicious of "we need to invest time paying down tech debt".
There's a big difference between "this code is horrific and can't be built upon" vs "ugh, this framework is so old, we need to rewrite it in Foo.js".
A VP of engineering pulled me aside after he saw that one of my proposals wasn’t getting traction and told me “None of the people who are writing alternatives to your proposal are doing the analysis you are, that’s why they look better than yours”
I guess I had never considered that a lot of my peers were just inventing numbers to justify things they wanted and that there’s a careful balance that needs to be struck between “making shit up” and “detailed unbiased analysis”