Maybe when you tell your engineers you need X feature implemented in two weeks, leaving them no time to plan or refactor, and they're building on an already bloated, ancient spaghetti codebase because every deadline has been two weeks under a skeleton crew for the past decade...

They have very little agency. Priorities are driven by OKR’s, which require measurability as one of the core tenants. If you want to accomplish something, you must be able to point at a number somewhere, and have a plan to make it to up and to the right. Refactorings to pay down tech debt rarely can pass as OKR’s unless there is a true business need.

This is a feature, not a bug, as far as management is concerned. They’re often proud of saying things like “if you can’t measure it, it doesn’t exist.” There’s often managers that are very sympathetic to the idea of pushing for quality, but then they’ll ultimately say something like “but, if you can’t come up with a number to show benefit, perhaps it really isn’t worth pursuing ¯\_(ツ)_/¯” and we move on to the next feature.

The only way any real quality improvement happens, is if motivated individuals do the work basically on their own time. You will not get organizational support for it. If you’re lucky, it will pan out and an improvement will be made. If you’re not, maybe your refactoring causes a regression somewhere (nobody’s perfect!), someone notices, and if that person is particularly angry about it you’ll get yelled at for making “rogue changes” that cause bugs. If your rogue change was done in some other part of the codebase, you’ll probably have your access revoked (ie. others will be put on the approval chain to prevent you from making such changes again.)

Your post sort of boils down to me as "be annoying and measure stuff all the time" or "hope you get lucky". I think there's a middle ground in there but it's too easy to err on one side or the other ad a methodology and then get stuck - either you're ruled by OKRs and playing games with metrics and juking the stats all day, or you're shooting blindly in the dark with no direction or accountabilities.

Or you can trust your engineers to know where the quality issues are (they live in the code base all day) and trust that when they say fixing something is important, and that they can make a logical case for it, that it should mean something.

Quality doesn’t come from metrics, it comes from giving a shit.

On balance, devs have more agency than ever before, but they choose to use it to load in every daft technology imaginable that makes their resume look good. IMO developers are less and less inclined to act like professionals that bring data to the decision table, so as to create meaningful business solutions.

Take scaling for instance: there is such a thing as unnecessary scaling. I've seen junior devs in AWS shops insist on embedding insane levels of serverless AWS tech, all to serve minimal systems with minimal data and bandwidth and minimal customers. When questioned about the drivers for all of this scaling, they have no reply - its all fairly obvious that they feel that they do not have a career without all of the latest TLAs on their resume.

Apart from creating billions for Jeff Bezos, this is creating bloat on staggering levels. PMs are often unable (or unwilling) to push back, because who wants to questions devs these days?

> I've seen junior devs in AWS shops insist on embedding insane levels of serverless AWS tech

I see senior devs doing that all the time as well; they have resumes to work on as well. Applications that probably will not get more than a few 10000 hits a day, if that, getting set up and stress tested so someone can say ‘set up app that could handle millions of hits a minute’. All on the company’s dime of course.