Whats the best way to hand over code that you were the sole owner of when leaving a company?

Question

If you have been working solely on a project for the last 12 months and are now leaving the company what would be your steps of handing over your code and knowledge?

Due to the business requiring quick to market solutions, very little documentation has been written. The code uses MVC with linq2sql and is very clear (in my own mind) of how the code is structured, where it is heading and also strengths and weaknesses.

The business also relies heavily on face-to-face communication with a developer for quick improvements and longer substantial pieces of work and there are no other developers in this office.

• Would you start writing documentation now?
• Create internal wiki articles to help other developers?
• Walk through code with other developers?

Answer 1

In the past, I've done:

1. Flowcharts. Knowing where the data is entering and leaving the system is key to understanding it.
2. A wiki for documentation. It's useful because it's simple to edit, it's going to stay in one place (multiple copies of documentation = disaster) and if other devs down the road see a problem with it, they're likely to fix it right away as well.
3. Set up a code walkthrough. If you have the time, do it AFTER you have the documentation in place, so if there are any questions, you can update the documentation appropriately. If there isn't time, still at least give them the walkthrough.

Answer 2

I would say to create a basic architecture diagram listing out how all the big sections work with each other and leave it at that.

After that, work out with the company a plan to have you work 4 hours a day, one day a week for the next month or so to answer any questions your replacement might have for you.

I find that this method really works the best. The company gets someone else who can start 'doing' something right away, but still has you as a safety net to keep him from churning for weeks because he does not understand some weird interaction.

Answer 3

I would walk through and document a (typical) scenario of, say, the last time you were asked to make a change. Where a developer would start, what code to look at, etc.

Ideally I would document the code well. Once that is done, make some general documentation - how to build it, the high level design, configuration, deployment, testing (how to), dependencies, layout of source tree, etc.

Then write more specific docs.

I have found that handover walkthroughs never are useful unless the new person actually has a task to do. Otherwise it is a waste of time.

Also, your comments:

Due to the business requiring quick to market solutions, very little documentation has been written

implies that docs get in the way of quick time to market. That is a fallacy.