Usually understanding a new, large code base comes in at least three phases. 1. At first, they always look like overcomplicated incomprehensible crap. Every li

Usually understanding a new, large code base comes in at least three phases. 1. At first, they always look like overcomplicated incomprehensible crap. Every little thing that you would have done in way X but was done in way Y initially looks like that. 2. But much later on, after you struggled a lot with making changes to the code base, things start to click. You understand why things were made as they were, what the constraints and requirements were. When you want to make changes, you know where they are supposed to go. 3. Then after much more time, it will look like overcomplicated crap again as you understand that people should have said "no" to the more bizarre of the requests, and that much easier solutions for some of the other things exist. The original programmers started out somewhere between two and three, and as long as they stay involved, they can always guide people, tell them where their changes go or whether they are ill advised. They know which parts are essential to the architecture and which were never meant as more than temporary crap. You get problems when none of the original programmers are still involved, and you only get people who have to climb the ladder by themselves. Or only have some people in step 1 left. Then the project is dead.