I've recently had to do this a couple of times. One I decided we could take on, one seemed to be beyond saving (cheaply). The main things I've taken from those experiences are: - Taking on another developer's work is always going to be hard and the first day or so will probably make your head spin in complete bewilderment - Try to resist the urge to rewrite unless it's absolutely necessary (and even then think again) - Don't be too disparaging of the previous developer's work, either of the code or documentation, as it won't help you and in the course of a project there are often reasons why corners have been cut (e.g. time constraints, changing brief) that you probably won't know about - if it's anything like most long-term projects then the requirements will have changed and the code design will probably have been bent to fit its purpose in a few places. On the plus side, it's a good point to get a fresh perspective on the problem. Hope that's some help, Karl > -----Original Message----- > From: thelist-bounces at lists.evolt.org > [mailto:thelist-bounces at lists.evolt.org] On Behalf Of > evolt at mccullough-net.com > Sent: 03 August 2004 14:12 > To: thelist at lists.evolt.org > Subject: [thelist] new situation > > > > I am looking at going into a company and having to look at > what the previous > developer did, and learn their whole process and what the > code looks like and > so on. > > However, and theres always a however. I got the distinct > impression that the > documentation is sparce, if there is any at all. Its a > tomcat/mysql setup. I > have asked for the layout and architure of the network and > servers, more of a > topographical map, code, database structure and data export, > any and all > documentation as well as some resumes from the support staff. > Going to ask > for the versions of the various applications. > > Any thing that has helped you guys in the past get > information quickly?