Like so many of these questions, I think the answer is:
There is reason to believe that taking the position that every programmer should know every line of code is misguided.
If we assume for a moment that someone with a deep understanding of a piece of code will make changes 5 times faster than someone who doesn't know it at all (not a giant leap of faith in my experience) and it takes about a month of coding experience to get a really good understanding of a significantly sized module (also not unreasonable) then we can run some (completely bogus and fictitious) numbers:
- Programmer A: has deep understanding
- Programmer B: none
Lets say programmer A gets 1 unit of work done per day. In 4 weeks of 5 workdays he/she can get 20 units of work done.
So programmer B, starting at 0.2 units of work per day, and ending with 0.96 units of work on his/her 20th day (on the 21st day they're as good as programmer A), will accomplish 11.6 units of work in the same 20 day period. During that month programmer B achieved 58% efficiency compared with programmer A. However, you now have another programmer who knows that module as well as the first one.
Of course, on a decent sized project, you might have... 50 modules? So getting familiar with all of them takes you about 4 years, and that means the learning programmer is, on average, working at 58% efficiency compared to programmer A... hmmm.
So consider this scenario: same programmers, same project (A knows it all, and B knows none of it.) Lets say there are 250 working days in the year. Lets assume that the workload is randomly distributed over the 50 modules. If we split both programmers evenly, A and B both get 5 working days on each module. A can do 5 units of work on each module, but B only gets, according to my little Excel simulation, 1.4 units of work done on each module. Total (A + B) is 6.4 units of work per module. That's because B spends most of their time without any skill with the module they're working on.
In this situation, it's more optimal to have B focus on a smaller subset of modules. If B focuses on only 25 modules, they get 10 days on each, totalling 3.8 units of work on each. Programmer A could then spend 7 days each on the 25 modules that B isn't working on, and 3 days each working on the same ones as B. Total productivity ranges from 6.8 to 7 units per module, averaging 6.9, and that's significantly higher than the 6.4 units per module we got done when A and B spread the work evenly.
As we narrow the scope of modules that B works on, we get even more efficiency (up to a point).
I would also argue that someone who doesn't know as much about a module will interrupt the person who does a lot more than someone with more experience. So these numbers above don't take into account that the more time B spends on code they don't understand, the more of A's time they take up by asking questions, and sometimes A having to help fix or troubleshoot what B did. Training someone up is a time consuming activity.
That's why I think the optimal solution has to be based on questions like:
- How big is your team? Does it make sense to have everyone cross trained on every part, or if we have a 10 person team, can we just make sure each module is known by at least 3 people? (With 10 programmers and 50 modules, each programmer has to know 15 modules to get 3x coverage.)
- How is your employee turnover? If you're turning over employees at an average of every 3 years, and it takes longer than that to really know every corner of the system, then they won't be around long enough for the training to pay itself back.
- Do you really need an expert to diagnose a problem? A lot of people use the excuse, "what if that person goes on vacation", but I've been called in numerous times to diagnose a problem in a system that I've had no experience with. It might be true that the experienced person could find it a lot faster, but it doesn't mean you can't live without them for a week or two. Few software systems are so mission critical that the problem has to be diagnosed in 1 hour instead of 5 hours or the world will end. You have to weigh these risks.
That's why I think "it depends". You don't want to split 20 modules between two programmers right down the middle (10 each), because then you have no flexibility, but you also don't want to cross train 10 programmers on all 50 modules because you lose a lot of efficiency and you don't need that much redundancy.