There's a variety of reasons. It's often because our languages are too low-level and the architecture too opaque, such that you need to study a codebase for a l

There's a variety of reasons. It's often because our languages are too low-level and the architecture too opaque, such that you need to study a codebase for a long time to understand what works well and what doesn't work so well. The hill you need to climb to reach an epiphany is sufficiently steep that people much rather build their own hill, and learn their own lessons. The trade-offs come around and around, the lessons are not as inapplicable as you think. We used to struggle to run programs on small machines; those struggles came back again with mobile, and come back again in a slightly different guise in clusters (where the program is too big to fit on any one machine). They recur on different scales, too. Just the other day I was looking at dependency injection. Dependency injection solves the problem of coordinating dynamic program composition; the reason the program needs to be composed is because it was decomposed for testing. But this is just another iteration of the same pattern come around again. It's been done before in a large variety of ways; sometimes through ambient configuration (global variables), sometimes with patched jump tables (dynamic linking), sometimes statically (module instantiation). The emphasis is different - testing - but the solution is not structurally novel in the least.