What should you leave behind for your successors? [duplicate]

Question

This question already has an answer here:

• How do you go about training a replacement? 6 answers
• job handover checklist [duplicate] 4 answers

Assume that you're a sole developer leaving a job. What kind of information/material, outside of the code itself, should you create and leave behind for your replacement?

An obvious answer is "whatever you would want at a new job" for sure, but it's been a while since I started a new job, and I forget what the most important things that I needed were back then.

I'm thinking:

• accounts/passwords
• location of equipiment

What else?

Answer 1

• Accounts & Passwords
• Server information
• Good code
• Documentation
  • Database diagrams & explanations are amazing
  • List of oddities in the code
• Procedures
• Explanation of manual processes, or occasional, non-obvious, work
• List of programs they used or found helpful
• Contact information ;)

Answer 2

A strong cup of coffee and an apology note.

Is what I wish I was left.

• Documentation. How hard is it to write a few comments? Build notes, deployment notes, moving the system notes. What to do when you restart and everything is gone.
• Papers. Write up why it's being done this way so I don't have to wonder why you aren't doing it another way. How does the backup system work, how does the server respond to loads, testing, test cases, use cases.
• Notes. "When using the database, don't ever say SELECT * FROM clients. We aren't sure why but it dumps the database".

Answer 3

This is begging for a down-vote, but three envelopes...

A fellow had just been hired as the new CEO of a large high tech corporation. The CEO who was stepping down met with him privately and presented him with three numbered envelopes. "Open these if you run up against a problem you don't think you can solve," he said.

Well, things went along pretty smoothly, but six months later, sales took a downturn and he was really catching a lot of heat. About at his wit's end, he remembered the envelopes. He went to his drawer and took out the first envelope. The message read, "Blame your predecessor."

The new CEO called a press conference and tactfully laid the blame at the feet of the previous CEO. Satisfied with his comments, the press -- and Wall Street - responded positively, sales began to pick up and the problem was soon behind him.

About a year later, the company was again experiencing a slight dip in sales, combined with serious product problems. Having learned from his previous experience, the CEO quickly opened the second envelope. The message read, "Reorganize." This he did, and the company quickly rebounded.

After several consecutive profitable quarters, the company once again fell on difficult times. The CEO went to his office, closed the door and opened the third envelope.

The message said, "Prepare three envelopes."

Answer 4

My email address, or perhaps even phone number.

In my experience it's difficult to get every detail written down, so the best thing is to be available (to a certain degree) if your successors need more information.

Answer 5

Documentation of the programs you have written e.g. their purpose, location of source files for future development, passwords, etc..

This can either be within the code as a comment or outside in plain sight.

Answer 6

More than just documentation, I'd like to know why certain decisions were made when they were made. We're using SWIG currently on a project and one of the other developers wanted to know why we just didn't use Boost::Python. The simple answer was that the customer did not allow the use of Boost at the time. Now is a different story.

Such things will help them not only in understanding the project but also what limitations/constraints/challenges your implementation overcame. It'll give them a starting point for future maintenance and feature augmentation.

Answer 7

If it is a desktop program, how to build the entire system from scratch (may be several separate programs), how to create a package for distribution (what dependencies it has, e.g. versions of .NET), and how to deploy it to servers for download if that is applicable, or burn it to a CD or DVD.

If it is a web-based program, FTP and (if applicable) SSH access to the server, and what tools are used to locally create and test the code.

If it is an embedded system, complete instructions on building the binary image, what tools are used, how to download and flash the code into the product, how to set up the filesystem on the device, if any.

Answer 8

One thing I didn't see anyone else mention (although I might have overlooked it) is to document how to setup a dev environment. I realize that most of the time it's just install a few things, get latest, compile and you're done. However sometimes there's more to it than that (SharePoint is one situation that comes to mind) and documenting what flux capacitator has to be configured in what way will be very helpful for the poor soul following you.

Answer 9

We'd all like a complete data flow diagram of the system with a list of functional requirements. More than likely you never got that when you wrote the system in the first place ! Like most places the best documentation is probably the code itself so what I would love most is well documented code. Lines and lines of comments in the code explaining what you are trying to do both technically and functionally.

Answer 10

I just recently left a job in similar circumstances to you (I wasn't the only developer, but there was really only two of us, so I had quite a lot of knowledge that the other guy didn't have (and vice versa, of course)).

In terms of the normal documentation stuff, it's important to document an overview of the whole system. Individual components are already documented in the code, but the interaction between components and why this does that or why this needs to talk to that component are important and not always easy to figure out just by debugging/looking at the code.

Then, for about a month before I left, every time I did something that only I could do, I wrote down exactly what happened, what I had to do, and why. This was usually a case of "there was a bug in xyz component, to fix it I knew to look in file abc because of X, then I had to do this, this and this".

Of course, I left my email address and phone number in case anything came up that they couldn't figure out on their own. I got a few calls in the first few weeks, but they slowly dropped off.

Answer 11

The #1 rule for documentation is not what it does but why. What's the backstory on the programs that run, and what they do?