Find the edges and work your way in. Find the core and work your way out. The edges depend on what kind of application you're talking about. A web app will h

Find the edges and work your way in. Find the core and work your way out. The edges depend on what kind of application you're talking about. A web app will have different edges than a GUI app, and so forth. Find the main method or equivalent, and follow the trail of instantiation. Usually you'll find that configuration takes place somewhere in this code path, which is another place to come back to later and start connecting the dots. When all else fails, identify and follow a single trail of execution all the way through the code. Find another and follow it. Pretty soon you'll start to get a sense of where to find the core of the code. Identify the presentation classes and work back from them to identify the business logic. Identify the data access layer (either file or database) and look at the app in terms of what it's pushing into and pulling out of the data. There are some code analysis tools out there, though I've never managed to quite fully grasp them, using them to look at the code can sometimes help you get a sense of the structure. One that is tantalizing, for java, is SA4J aka Small Worlds: http://www.theserverside.com/news/thread.tss?thread_id=24255 http://www.theserverside.com/news/thread.tss?thread_id=24255 There are others out there. There used to be a copy&paste detection tool in sourceforge... I might be thinking of this one: http://pmd.sourceforge.net/cpd.html http://pmd.sourceforge.net/cpd.html Add comprehensive logging: Add a log statement for all method/subroutine/function/procedures, and then run the app while watching the logs, to get a sense of what gets called, when. You can try to go a step further, and log all returns (and the values returned) but that can be a more challenging task. On the other hand, figuring out where to insert those log statements will also force you to engage with the code, so it's worth it if you've already picked the other low-hanging fruit. Speaking of engaging with the code; don't underestimate the value of refactoring the code as a way of learning your way around it. It's much more engaging and less likely to induce highway hypnosis if you're actively working the code instead of just skimming it. Obviously you use good revision control, and ideally keep a pristine install of the code alongside your experimental working working set, to compare behaviors. Don't be afraid to throw away the refactored code if you find you've bogged down (and keeping that clearly in mind can help you avoid analysis paralysis). Good luck, Jim!