[dotancohen]

  > because they will on paper be producing more features for less financial cost.

And from a business perspective, that is the correct choice.

So make a better business case. Inform them that after investing Y hours on refactoring X, future development is expected to happen M% faster with N% less bugs. New features can be expected to be developed, tested, and shipped to production in S% less time.

But be realistic. Don't make promises that you won't actually meet when the time comes.

[JohnBooty]

You're making this sound simpler than it is, I think. For the following discussion assume we're talking about management that is smart and wants the dev team(s) to succeed but is racing hard to hit various external deadlines and does not have a technical background.

    Inform them that after investing Y hours on 
    refactoring X, future development is expected 
    to happen M% faster with N% less bugs. 

I've tried variations of this to sporadic effect. My elevator pitch is/was essentially, "let's devote 10% of our developer resources to making the other 90% more productive, rather than having 100% of our developers suffer these slowdowns and problems."

(I chose 10% because we had 30 developers at the time and generally had teams of 3 developers. So, one dedicated DX team...)

Do you have any articles, case studies, etc of how to express this to management that is generally oblivious to the day-to-day, in-the-trenches, experiences and pain points of developers?

What you're saying sounds great to me, who is a developer, but how would you come up with halfway realistic numbers for Y and X?

The best thing I could think to do is have the team minutely log all lost minutes productivity caused by delays and inefficiencies that the proposed fixes could address.

But even that's tricky. For example, at one of my previous positions, the build pipeline could take hours and could randomly fail.

The only way to maintain any semblance of productivity would be to juggle 3-4 tickets at once. This was incredibly challenging, and productivity took a massive hit due to the frustration and context switching.

However, even if I had logged those experiences down to the minute, there weren't any literal downtime minutes. It was more a matter of juggling five tickets at once that should have taken one hour each, but instead they took five hours each because I was context switching faster than the Linux kernel itself.

    New features can be expected to be developed, 
    tested, and shipped to production in S% less time.

This sounds good to me, a developer but again, I'm not sure how to express this to management. It's not like "one feature" is some standard unit of measurement - the time to shipping "one feature" varies by orders of magnitude.

Scrum and its much-maligned "story points" are a possible solution here, as far as management is concerned, assuming both developers and management have bought into that concept and are using it correctly.

[dotancohen]

  > Do you have any articles, case studies, etc of how to express this to management that is
  > generally oblivious to the day-to-day, in-the-trenches, experiences and pain points of developers?

It is the "generally oblivious" that is the problem. Log holdups whenever a ticket takes significantly longer than the estimate. And be specific as to what the holdup was.

  > What you're saying sounds great to me, who is a developer, but how would you come up with halfway realistic numbers for Y and X?

The same way that I come up with halfway realistic numbers for any other dev work. I pull it out of my donkey. Then double it.

  > The best thing I could think to do is have the team minutely log all lost minutes productivity
  > caused by delays and inefficiencies that the proposed fixes could address.

Yes, log it! It does not have to be by the minute. Honestly, if the holdups are only causing minutes of delays, then they're not so bad unless your ticket take only minutes to complete anyway. My general rule is to log any holdup of more than half an hour, or more than 10% of the time estimated to develop a feature/bugfix. Very loosely, of course.