Enterprise programming is the management of system complexity. The main goals of most enterprise projects are to minimize bugs, ensure scalability, and release as soon as possible. These goals are unreachable in projects where people rely on individual skills rather than on a system-based approach.
You know what attribute of a code base is more valuable than any other? Maintainability.
Every project ever should emphasize maintainability over performance, cleverness, etc… because this is the true long term cost of code. If it’s difficult to understand why or how something is how it is then you’ll pay a lot more to bugfix it and improve it over time.
This attribute is opposed (mostly) to flexible prototyping so a really good senior dev will be able to transition a greenfield project into one that’s structured for long term usability.
That’s cool if people can agree on what maintainability is, which changes improve it and which changes hurt it.
You can get two people arguing for the exact opposite thing, while both of them use maintainability as an argument.
And you’re never going to get an easily maintainable code base without enabling those really good senior devs who can do that. It’s more nuanced than the author of the article thinks, sometimes an unweildly process gets in the way of making changes required to improve maintainability.