Taking over a project - What should I ask the previous programmer?
DocumentationProjectDocumentation Problem Overview
I'm taking over a development of a commercial web site. This site was developed over two years by another programmer. It's mostly a one-man job (maintain and expand the site). I'll have a 2-3 days transition period when the other programmer will show me the system. But from what I know, there is little documentation. Everything is in the code (which is kind of documented). Here is what I'm planning to ask so far:
- Explanation on the most complex elements of the system
- Description of the overall architecture
- Description of the support tools (IDE setup, unit tests, deployment mechanism)
- Any book, website, podcast he used to influence the architecture of the system
Any other I'm missing?
[EDIT] Thanks everyone. Lost of good propositions. I wished I could accept more than one answer! Additionally, I would also add:
- What have you done specifically to improve the performance of the system, and where is the bottleneck right now?
- Related to that, what have you done regarding the security of the system? (what have you done, and where are the security holes right now)
One last thing: the developer said that he will be available to to answer my questions later on if I need it. It's his "baby" after all. But I really think that in 6 months he will have moved on and his availability will be much more reduced!
Documentation Solutions
Solution 1 - Documentation
Before you look at the code:
Clear the objs and the exes, and let him/her rebuild the thing. Watch for any manual interaction (does it build via "make" alone or is there some fiddling involved).
Better yet: give him/her a naked (just bought) machine, let him/her demonstrate a checkout and rebuild. Then see how the app is started and comes up (any secret options to input?).
Then: in a pair programming session, add one or two features to the system and see where and how these are implemented.
The above may sound stupid, but I have seen projects where building alone was a nightmare, and a lot of knowledge was in the brain of the developer only. Not having a trusted build environment and having to figure out how to rebuild is a nighmare.
Solution 2 - Documentation
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.
Solution 3 - Documentation
"If you could go back and redevelop this system, what would you do differently"
Solution 4 - Documentation
Ask: a) what don't you want me to ask you about this system? b) what will you be most happy about when you are no longer working on this project? c) What are the parts of the system that are too complex to be documented?
Solution 5 - Documentation
His phone.
Solution 6 - Documentation
Who are your expert users - whose opinion should I seek or trust?
Who are your dangerous non-expert users - who should I listen to and then actively ignore?
Solution 7 - Documentation
- Known1 issues
- Known1 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
1 Known only to him or her
Solution 8 - Documentation
What is the periodic "hand work" that the system requires?
You know, those little jobs that crop up every so often that haven't been automated yet. How do you fix it and how do you recognize it.
Solution 9 - Documentation
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.
Solution 10 - Documentation
The first question I usually ask when taking over a project is how to get it out of source control (basically, "Where is it?"). Other than that, I think you've hit all the high points.
> IDE setup, unit tests, deployment mechanism
are probably the most important things you can ask about.
When asking what websites influenced the one you're taking over, make sure you get a list of links. I've found that a lot of developers keep bookmarks to sites they've sampled from. Make sure you get those.
Solution 11 - Documentation
Make sure you can BUILD IT and RELEASE IT.
Too many times there are problems with missing information.
You need to KNOW ALL THE ancillary stuff.
Get a fresh machine and make sure you can duplicate a build and release.
EDIT: after that it would be: "What are all the things you have been meaning to fix but did not get to and are not documented anywhere"?
Solution 12 - Documentation
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.
Solution 13 - Documentation
- How you would install the site on a brand new server.
- What the site does & what it's used for.
- What databases are used & where they are.
Solution 14 - Documentation
Make sure to get all the "gotchas" for the application. They are often the data or business items that are too minute or quirky to have formal documentation, but wind up having big impacts or lots of debug time if you don't know what's going on.
For instance, in one of the applications I currently maintain, we interface with a third party system that has a "web viewer" type client. The "gotcha" with this is that the web viewer doesn't properly maintain the user's session state (broken when it was updated to their latest version to fix other critical issues). As a result, I have to remind the users from time to time to simply minimize the browser window so that the timeout occurs naturally, otherwise they will get locked out for a prolonged period of time until the Ops folks around here get the newer version installed.
Solution 15 - Documentation
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..."
Solution 16 - Documentation
As well as the techy stuff (that's 'easy' to figure out :)) find out about the business rules! These are rarely documented properly (in my experience) and you usually only find out the hard way when something goes wrong.
Solution 17 - Documentation
2 to 3 days sounds short for the handover so don't be afraid to ask for more.
First get a working local environment with source control, ide, build and release steps all up on running locally.
Then try and get an impression of the code quality by going through it briefly. If it looks bad then you may not get so much useful information regarding the implementation from your predecessor.
However everything regarding deployments, db servers, backup strategy , registrations etc. should be checked. Also all licenses for libraries etc and also a list of the most common errors (if they have a bug tracker tool this may be useful)
Also you need to see how helpful your predecessor is as I've seen several styles of handover form ones where the person giving the handover was friendly but misleading to where they gave sarcastic answers to the questions asked of them in a form of a questionaire (which while funny wasn't professional) to just plain disinterested.
Solution 18 - Documentation
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.
Solution 19 - Documentation
Carefully review the application and try to figure it out first. Then go into your meeting with questions, and most importantly, context.
Solution 20 - Documentation
Have you been working at the same company?
If not, and this is not directly related to the project, but I'd ask him why he's leaving. It may give you some insight into the politics involved or if anything is bothering him working with it or with the client.
Solution 21 - Documentation
Ask about any roadblocks or work-arounds the original developer came across.
Learn about your customers as well. Are they picky? What do they expect?