[thelist] new situation

[Karl Bunyan]

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?