[whb07]

I'd like to point out that if it is truly large, then deep intimate knowledge of specific parts will never be truly had. Those who do know the entire project understand the flow and architecture of it but the details are blurred.

[khedoros1]

That's what I was thinking. My first job was dev on a C++ and Java project that was in the high hundreds of thousands of lines when I started, and grew from there. Client-side had about 5 core binaries, server side had about a dozen, and each of those was a sizeable file.

Starting to understand it involved reading our documentation on the data-flow between different components during operation, to know the purposes of the important binaries. For the really core components, we had a fair bit of documentation at the level of classes.

You'd usually end up learning the sections of particular programs that you worked on in great detail, the programs themselves as a whole in slightly less detail, getting fuzzier as you moved away from your areas of greatest experience.

[gsam]

To add, close mentorship with a core member of the team is one of the ways to get around this hurdle. Anything less formal than that, in many cases, it's fairly impossible (unless you have some very similar experience you can draw from).

[markrages]

Naur explains this:

http://pages.cs.wisc.edu/~remzi/Naur.pdf