some time ago i though about characteristics of a good SW… and its design, as a matter of fact. i came to a conclusion, that good IT project is all about what you do NOT need to remember!
it's quite simple, if you think about it. if you are in a shitty, legacy project, you'll notice local system experts will have their heads full of “magic constants”, “hidden assumptions” and other “tribal knowledge”, that makes them effective in navigating through piles of historical-code-den. over years ppl can get used to it, and consider it a normal situation (a very dangerous stage of the IT carrier, if you ask me).
on the other hand if the SW is well designed and codded according to the best industry standards, most likely all you'll need to remember is a basic (top-level) overview of who-does-what. all the remaining elements you'll be able either to derive from that basic knowledge or find by quickly diving through abstraction layers. it will be easy, since the SW design is obvious and code is self-documented and divided into well-defined parts: subsystems, modules, libraries, services, etc…
since an average developer is said to be able to comprehend well about 50-100KLOC, for all bigger projects you need to be able to reason and find relevant places. if the design is in place and code is clean, you will be able to find anything in no-time. it will just be so obvious! :) in my carrier i had at least few occasions to benefit from that. working in these projects was a pleasure. when combined with good unit-test coverage, you could navigate easily and test your changes rapidly, at the same time. all of these leading to high quality and good productivity.
if you need to know any “yes, but”s – you're on a wrong track. turn around and rethink. as a good practice try to organize both design and code, in a way that will require you to remember the least things. this way you should come up with something simple that does the job and is maintainable. Occam's razor applied once more! :)