Tons of complex code and noone to share the local knowledge? Isn't it a setup for a failure... yet the org is still in business, probably generating revenue. S

Tons of complex code and noone to share the local knowledge? Isn't it a setup for a failure... yet the org is still in business, probably generating revenue. So, I'd say the leverage is as always in understanding the dynamic and politics that often brews in places with the "monstrous" codebases. Debug the people functions, so to speak, and it may eventually help you navigate that codebase. No one needs to be another hero, no one needs to burn-out while single-handedly fighting the beast! Well, politics often are messy and more unpleasant than the code at hand, so we dig and rant... In such case, I would try to limit the scope, instead of trying to learn the secret language of gods that stitched the whole system so it would make money. My rule #1: WTF?!...But they must have had a reason for that. Rule #2: Keep your code changes in-style; bug-free, of course, but similar idiomatically. Rule #3: Try to do something, then try to do it together with others. Maintaining a large codebase is not so much about tools as it is about finding ways not to do it alone.