I think for most decent engineers, if you have a small group of good ones, no matter the time pressures they'll deliver you something half decently architected -- most likely with understood compromises. Where things start to take a turn for the worse is when more people pile onto the codebase without the context to know what the trade-offs were or where the load-bearing paint is, get in, make changes and get out. Now nothing makes sense.

In order to safely make changes to any one part of a codebase, an engineer needs to understand how it all fits together and have all that context in their head to ensure changes don't have unintended consequences.

There are design patterns that make this easier of course and less error prone, but there's no enforcement at compile time, and with people coming and going it all goes out the window.

I think we can solve a lot of these problems with much, much stricter and smarter compilers. Eventually, I hope we'll all be writing software for which the compiler will be able to tell you authoritatively you've written the thing you set out to write and there are no bugs. As software complexity grows, no one or two people will be able to keep a whole understanding of the system in their heads (already true a most of the time). It follows for me that the only way to confidently make changes to a system you don't understand is to automate that understanding.

That's why I love what Rust stands for. It's a first step to be sure. However, it makes the assertion that the only way to allow people to reliably develop software they don't understand is to have the compiler 'understand' it for them (I use understand loosely of course).