The trouble is a lack of peers. For many years our codebase was completely maintained by no more than three people, and often just one or two. Two of those peop

The trouble is a lack of peers. For many years our codebase was completely maintained by no more than three people, and often just one or two. Two of those people are gone now (I'm the third) and we've been trying to increase the number of developers who know the codebase well. The tech leads are the in-house developers who have a range of experience on this codebase, from two years to a couple of months. The bulk of the developers are at an offshore subcontractor who has a very high turnover rate, our last project started with a team that mostly had no experience with the codebase, other than their tech lead. So yeah, two developers can review each others code, but if neither of them have much experience with the codebase they can't maintain quality very well. (We get a lot of cut-and-paste and magic-incantation coding from the inexperienced developers.) Slowly but surely we're improving things, and while I'm still the only developer with broad knowledge of the entire codebase, the others have become experienced with different parts of it, so I'm not the bottleneck I used to be. One nice thing about my company: while we've got a big-corporate bias for process-at-any-cost, we're pretty flexible about trying out different variations on the process with each project in order to improve our approach. It's slow going, much slower than it would be in a startup, but it's not the brain-dead process quagmire a lot of companies have either.