The book Working Effectively With Legacy Code has a chapter titled "I don't understand the code well enough to change it" and another "My application has no structure". They both provide some techniques to get the understanding. Personally, I think if you don't understand a codebase, and you need to, you should start with making an attempt to understand it before you do anything else (reverse engineering, etc. -- how could you convince higher-ups to get rid of it, or rewrite it, if no one understands what it's doing in the first place? What exactly are you getting rid of?). Sometimes deleting things and seeing who complains / what tests fail can help, sure. Anyway, the book doesn't offer anything too mindblowing, but I've found it helpful. Make diagrams of the system (they don't need to be formal, start with just writing down each important-looking thing you find, and noticing important-looking relationships), print out code and mark it up, deleting any code you think is dead code, do some scratch refactoring (extracting methods, moving things around, generally making tiny bits of code clearer in the hopes that eventually the larger program will become clearer too) that you don't actually need to worry about checking in, and there are a few methods of explaining the system you can use to verify that you're actually beginning to understand it and where you need to focus more efforts (telling the "story" of the system, describing things with a type of naked CRC technique)...