> high quality codebase armed with proper peer-reviews This is a No True Scotsman argument. Of course if you assume a process which prevents problems, you won'

> high quality codebase armed with proper peer-reviews This is a No True Scotsman argument. Of course if you assume a process which prevents problems, you won't get problems. I don't believe it though. People make compromises in the face of conflicting demands; technical debt is taken on in order to get features to market sooner. Developers churn; new developers are hired who have less context and take shortcuts, and other newer developers review and approve their code. In large systems, developers may have been working for years but still be unfamiliar with different corners of the codebase; newness is path dependent. > What if we couldn’t trust that parts in our cars and heavy machinery does what they say This analogy doesn't really fly. Software isn't subject to physical constraints on local action. Functions are abstractions. There's a handy rule of thumb about abstractions: don't create an abstraction until you have three different uses. Now I think functions are fairly lightweight abstractions and are generally malleable, so I wouldn't really apply it. But the principle behind the rule is still sound. Multiple users keep an abstraction honest. They stop it growing hairs and warts specific to a single user, which bleed hidden dependencies across the abstraction boundary.