At my (now former, thanks layoffs) company, we used to gripe about getting nontechnical management to understand how stupid it was to skimp on pre-prod funding . . . because pre-prod was our prod.

So is the recruiting pipeline. Kill that and you kill the company. Agents and AI can only do so much, the rest is people power. Sadly too many companies have broken recruiting processes.

Sounds like someone wants to go on-call.

You too can enjoy being paged at 2am for a flaky disk, a cron job related traffic spike, and AWS outage, or any of the wonderful things pagers get paged on.

And you can re-read your essay after being awakened repeatedly for false alerts, knowing that non-prod alerts are now first class citizens and you are their Shepherd.

Tldr? Go ahead and page yourself for non-prod alerts. No one will stop you.

Being a production system doesn't make it a priority.

> A team with a broken development pipeline can’t produce software, and must treat this as a production outage.

While I sympathize, I can't go that far. An "outage" means user- or stakeholder-facing.

To the extent that a developer is a stakeholder (surprisingly common) you might be right, and they would prioritize such processes.

Increasingly though founders and executive team are non-technical and simply don't care until it shows up on a graph that piques their interest (the ones with $ somewhere).

this muddying of terms is not useful. No, my IDE breaking down is not a production system failure. It's a development system failure and sure, that can very easily have consequences on the production system but usually not immediately. It should be obvious to everyone how having a functional hammer is going to be important if you want to fix a house. There is no need to start calling the hammer the house.

In my experience, most large companies do treat not being able to ship code (i.e. deploy to prod) as outages. Being on-call in a CI/CD infra team is fairly common.

Agreed that many parts of the development pipeline can be hit-or-miss. At scale, it's great to have a dedicated "Developer Experience/Tools" org, though I've seen mixed results even with one.

There is a weird duality when analyzing this... On the one hand, I think factory assembly lines are just a high bar to clear as as metaphor for internal processes. Almost no business actually runs a super organized backend workflow; there is always "I thought you followed up with the customer" "I thought you did"

On the other hand if the email server is down that's just as big a problem for any biz as if customer facing product was not working so some workflow things are already treated as production tier priority

I guess the problem is visibility. In the same way that many companies don't take security seriously until it becomes a problem. If a problem never manifests, but was prevented, was it really a problem?

Of course I know the importance of preventing problems, but how do you properly measure it? A data leak is immediately visible, but preventing them is less so.

There's more to making an argument than stating your conclusion forcefully and repeatedly.

EDIT. In particular the author hasn't acknowledged the prioritization problem, hasn't explained what factors might go into the necessary cost benefit analysis. The author merely points out "developer productivity is important!" You might as well say "invest in your tools!"