Taking over a project - What should I ask the previous programmer? [closed]

Answer 1

Looking at the code for 5mins is the best start, if the code is really well organized and commented, there might not be any reason to talk to him at all.

If the code is hideous, well don't expect any intelligent reasons why he hacked something together, at best you can use him as a reference for some cruddy code and asks what's the purpose.

Either way, talking to the past developer is the least useful thing to do because either way, you're stuck with it now.

Answer 2

Be sure to ask for all login information for the web servers, domain registrars, database servers, email servers, and anything else you can think of. It sounds crazy, but often times developers will register domain names with themselves as the administrative and technical contacts. The company will then have to jump through all sorts of hoops with the registrar in order to get the domain back, if the original programmer can't be contacted.

Answer 3

• Known¹ issues
• Known¹ areas of improvement
• Existing code coverage data, test pass rate etc. to be used as a baseline
• Troubleshooting tips (understanding log files, debugging crashes, common gotchas)
• Explanation of configuration parameters

¹ Known only to him or her

Answer 4

Don't ask. Lock him in a room - instruct him that he will not get food or water until he starts from the beginning and tells you everything he knows about the system. Then ask relevant questions as they come up. After this - spend a couple of days looking at the code. Then repeat the process. Do this until you feel comfortable with the system.

Answer 5

What the biggest problems that the site has run into have been and how they were solved? It's way too easy to try and fix something that doesn't make sense at all only to discover that what appears nonsensical is actually the only fix for some subtle but nasty bug.

Going through the code and looking at anything that looks at all hard to understand and just asking "what does this do, why did you add it?"

Make sure you write down their responses - perhaps even comment them in the code so they are there when you need them. There is nothing more annoying than that feeling of "I know I was told about this..."

Answer 6

Ask what the real requirements are. Most projects either have no have written requirements or out-of-date written requirements. The real documentation is usually verbal conversations. Find out who to talk to. If you have conflicting requirements from different users, find out who is most important to make happy.