Question : Digging in to somebody else's stuff

I have just taken a job where I will maintain & support 3 applications developed by 3 different developers. They are what I would term mid-size (300-500 objects). Does anybody have, or know of, any methodology for getting up to speed with an unfamiliar app?

The manager has directed me to clean out the un-used objects, streamline the existing processes where possible, and work up better documentation. These app's do some pretty complicated financial reporting, from data consolidated from spreadsheets.

I already have Total Access Analyzer, and I use Object Dependencies all the time. My question is more about how/where to dig in, in the most effective way possible.

So far, I have started at the main menu, and just worked my way out from there, but I can't help thinking there must be a smarter way to go about this. The manager is pretty familiar with the app's, and will walk me around in them, but I need to get my arms around them first, so I don't waste the walk-through's

Thanks

Answer : Digging in to somebody else's stuff

<>

 That's about it.   I also crusie through all the modules and try to get a sense of what's available as a foundation (common routines) vs stuff that is app specific.

 I also try and get a feel for the level of the development that was done; macros or code with poor logic, no error handling, etc, then I look at anything and everything when working through a process.

Stuff that appears a bit more professional (error handling, use of a naming convention, closing objects, etc) I don't bother as much going through the nitty-gritty details of everything unless there is a specific problem.

I also like to review the table design and try and spot any obvious flaws and where problems might result becaus of that.

Sometimes I will go through and rename objects, especially if a naming convetion was not used.  It also has the benefit of showing me where things were used and I can tell what I've looked over vs things I have not.

HTH
JimD.