I can make the exact same argument about automated regression tests. As the size of your codebase grows and the number of customers (i.e., people triggering edge cases) grows, unless you take conscious steps to make sure that every build doesn't regress previous bugs, all your effort will get sucked into diagnosing and fixing things that you've fixed before. And all your developers will be fixing bugs but you won't be fixing new bugs and certainly not shipping features.

In particular, if you want to refactor / rewrite parts of your code to improve development velocity, you'll suffer from the well-documented problem (see e.g. https://www.joelonsoftware.com/2000/04/06/things-you-should-... ) of losing all the knowledge of the weird edge cases you've fixed along the way. So, testing is strictly more important than development velocity!

I can make the same argument about a half-dozen other development best practices, and I'll have actual citations to back them up. Why is development speed the most important goal, why is formal process the enemy of speed (instead of its friend, because it makes sure work doesn't get duplicated or wasted!), and what is your evidence for these claims?

In particular, if your claim is true, we would not expect to see as much feature development / new products from old, large companies (I'm thinking of Oracle, Microsoft, Apple, Amazon, etc.) as we do. We would expect to see these companies grind to a halt and perform poorly in the markets (investors really want to see growth, not just continuing to be as good as you were last year), and that's not what's happening.

It's not a question of preventing formal processes, doing that indiscriminately is a recipe for disaster; every engineer will do things their own way, and once the head count exceeds the ability for everyone to talk to each other daily, there will be an explosion in complexity and duplicated effort. Rather, you need to put in the right processes, maintain them just as you would code, and kill them when they no longer serve the company. Where "process" goes wrong is when it's used as a hammer to address issues that would be better served by team structure, common tooling or architecture. For instance, if you have a quality issue, adding more code reviews will generally cost a lot more, and do a worse job than making the responsible team wear the pager for their own code.

The real secret sauce to staying agile as a company grows is small, cross-functional teams. This is where SOA (microservices for the kiddies) really pays for its overhead—by decoupling human teams and giving them agency. This won't make a big company as agile as a startup, because that's literally impossible, but Amazon and Facebook have shown how much more agile it can make you than any prior megacorp.