[vimwizard]

>The only times I've seen developer pain-points successfully addressed in a sustainable way, it's because there was a dedicated team allocated to that sort of thing: a "developer experience" team, or some equivalent.

I came to this conclusion after watching the place I work at for 2 and a half years fail to implement any of the grand ambitions management had in their heads. We wanted code review, pull requests, build pipelines, automated releases, updated OS's, logging, disaster recovery, you name it. No one had the experience, time, or energy to implement it, so it falls on one or two juniors (me) to quickly learn and implement while learning. No one is hired with experience in any of these topics, only fresh-grads that will replicate the garbage you're trying to get away from are hired, because they will on paper be producing more features for less financial cost.

[ownagefool]

I think they key is to find people who have put effort into figuring out what good is, and are frustrated and care enough to enact change.

Similarly to your org not having a dedicated DX team being the reason, dedicated teams will happily dissapear into a void of non-delivery as their purist vision, unconnected with reality, will simply never apply to your stack, and thus you'll never use it.

End of the day, different things work and fail. The key is almost always the quality of people, their motivation and how many road blocks you put in front of them.

[JohnBooty]

     dedicated teams will happily dissapear 
     into a void of non-delivery as their purist vision

I've sort of seen that happen, but of all the issues being discussed, that seems the easiest to avoid.

1. Rotate team members onto and off of the DX team, so they don't lose touch with reality.

and/or

2. Have the rest of developers vote (or otherwise have direct input on) on the DX team's priorities and products. The other developers are the stakeholders here.

[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.