Posted by a.hay on 10 October 2013 - 1:01pm 

By David Worth, Principal Investigator at the Software Engineering Support Centre.

So the lure of a better salary proved too much for your developer, or perhaps they needed to start work on something new. Whatever the reason, you need to make sure that whoever picks up the development reins has all the necessary information. Here are some tips that will smooth that transition.

Start early

It takes longer than you think to transfer the knowledge necessary to make certain that a new developer can continue development. It takes even longer to work out exactly what information needs to be passed on. Put simply, it’s not just about understanding the code.

Start really early

You knew this day would come. When you started developing the software, you hoped it would be the best in its field, used by millions and endure for decades. Yet this couldn’t happen without changes in the development team – be it new people joining or old people leaving. So, you need to use good software engineering practices and make sure to write down requirements, have a design written down, implement the code with an excellent commenting function and making full use of version control, create developer and user documentation, and use tests to make sure the software remains fit for use.

All this information should be easily available to the new developer, alongside a description of the development process. It will give him or her confidence that they are doing it right, they understand the code, they know how best to modify it and they don’t break it.

Write it all down

Standard software engineering documents are a fantastic asset to a new developer, but if I could only have one thing, it would be good code commenting. With suitable tools such as doxygen, you can construct function call trees or class diagrams, while appropriately formatted comments allow you to get full developer documentation.

However, there is a great deal of other useful information that is available but in an encoded form. What you need to include are things like:

• How does a user build the software? Do you have makefiles, use ant, a script or rely on an IDE?
• How do you run the tests? Does this involve a rule in the build system, automatic testing from revision control repository, a script, testing by hand or from within an IDE?
• How do you use revision control? Does this feature branching and merging or tagging, and where is the latest version for release?
• What systems do you use to build and test the software? This will include log-in details, support libraries and so on.
• How do users access the software? Is it through official releases – and if so, how are they circulated? Are they available from revision control?
• How do you interact with users? Do they have access to bug and feature trackers, personal email and group email?
• What licence do you use for the software, and what is its impact on libraries you can use?

In our group we use wikis as a quick way to keep on-line documentation. These are a great medium for hand-over information as links between data can be made explicit. For example, the details of the testing regime can point to the configuration of the test machine and to the log-in details.

Talk before they walk

This is not the end of the story - the information should be shared face to face as well. Having a complete set of information available for when your developer has gone is of course essential, but remember that it was written by someone who understood the systems, processes and software intimately and there may be gaps only an outsider will spot.

So, if possible, arrange for the new and old developers to get together to go through the handover information. If the new developer hasn’t started yet then use someone else who could identify where more detail is needed. I wouldn’t recommend doing it all in one day – that’s a recipe for information overload! Instead have several sessions that will give the newbie time to check the accuracy of the information, try out the revision control process, make a dummy release, find documentation and come back with questions.

Oh, and if all that fails, make sure you can contact the deserter (surely the best dev you’ve ever had? – Ed.) just in case something vital got forgotten!

Thanks to colleagues at the Software Engineering Support Centre for their comments.