Good practices for handling project over to another developer

Question

What are some good procedures to follow when handing a project to another developer, in cases of when the original developer will still be around for a couple of months to aid in the transition? Let's assume a medium-sized web application if a concrete example is necessary.

Answer 1

If you have written your code from the start so that it is sensibly architected and fairly simple to understand, and provided adequate documentation, transitional problems should be minimal.

But training is always nice.

Answer 2

As a junior developer, I have gotten several projects assigned to me for maintainance that were written by others. I believe the easiest projects to continue are the ones where the code is clean and well documented (meaningful var names and formatting as well), the archetecture is relatively strightfoward, and the developer took some time to write some notes on the use of his components. In Java this would include class-level javadoc; in other languages it may include a header at the top of the source code.

Also, if the original developer is available and open to questions, it makes learning the archetecture much simpler - no puzzling out what he was thinking.

Answer 3

I've been on both ends. Taking over a code base and handing it off.

You should:

• Identify areas that aren't completely obvious. So, if you have a directory called "xml" but all your flash object get their data from "flash/swfs/xml" you should document that.
• Identify parts of the database which are no longer in use. If there are tables that simply have no use anymore.
• Identify areas of concern such as speed/performance of certain pages.
• If you have some really backwards logic on certain pages, explain why, if it's not been commented in the code directly.
• Any third party vendors should be identified along with their cost and use on the site. So if you're using a delivery network to stream your flash videos, definitely let that be known.
• If you have pages still in the project, but aren't being used anymore, identify them, or simply remove them.
• If you know for a fact that your database was poorly designed, contains no constraints or indexes and has no primary keys on many tables, mention it. It will let the new developer know they need to optimize the database.
• If you hardcoded e-mail addresses within the code and didn't put them in .config files, identify that as well.

I'm sure there are more but there are things I wish were brought to my attention on a project I had taken over at one point.