Discussions of software architecture give the impression that the only concern is the problem domain: how to structure a content management system, how to structure a word processor, etc. This leaves out the people who will be developing the software.
How much do you trust your software developers? How much do you trust their skill and their integrity? Do you want to get out of your developers’ way or do you want to protect yourself against incompetent developers?
This is uncomfortable to talk about, and so the decision is usually left implicit. Nobody wants to say out loud that they’re designing software for an army of mediocre programmers to implement, but that is the default assumption. And rightfully so. Most developers have middling ability, by definition.
(At this point we could go on a rabbit trail debating cause and effect. People rise (and sink) to expectations. One could argue that the assumption of mediocrity is self-fulfilling, and to some extent it is. On the other hand, treating a script kiddie like Donald Knuth isn’t going to make him into another Donald Knuth.)
When outstanding programmers complain about common approaches to developing software, they may not consider that most software is not written by outstanding programmers and what a difference that makes. For example, I’ve heard countless great programmers complain about Java. But Java wasn’t written for great programmers. It was written for average programmers. The restrictions in the language that great programmers chafe at are beneficial to teams of average programmers.
If you trust that your developers are highly competent and self-disciplined, you’ll organize your software differently than if you assume developers have mediocre skill and discipline. One way this shows up is the extent that you’re willing to rely on convention to maintain order. For example, the architecture behind Emacs is remarkably simple and highly dependent on convention. This approach has served Emacs quite well, but it wouldn’t work for a large team of mediocre developers. (It also wouldn’t work for software controlling a car’s brakes. Bugs in text editors don’t have the same consequences.)
In general, I see more reliance on convention in open source projects than in enterprise projects. A possible explanation is that open source projects have more motivated developers. Not all open source developers are volunteers, but many are. And not only are volunteers more motivated, they’re also easier to dismiss than employees. If someone’s code isn’t up to standard, the project can simply refuse to use their code. In theory the same could be said of an enterprise software project, but in practice it’s not that simple.