Folks have given you good advice above, to which I'll add this: Once a project gets past the point where you can expect to have most of the team members keep the code live in their heads, you'll need a set of diagrams to describe the system. These diagrams can be simple (say, a few UML object diagrams, plus some key sequence diagrams, plus any key state charts). Any more than you can post on the side of a cubicle is too much, in my experience.

Having a set of diagrams makes it a lot easier to bring someone new up to speed, especially with a large code base. Having a few good diagrams also streamlines design sessions. If you're in disagreement, at least you'll know that you're disagreeing about the same thing.