Knowledge Transfer and software development [duplicate]

Question

I have been working on an application alone for several years.

I am now asked to transfer knowledge to a few other developers, which I think is a good idea because it will allow us to share the workload.

The problem is that I have never been involved in such a process. My manager is asking what I need to facilitate this process. Are there any formal processes/tools/techniques that relate to knowledge transfer and software development that I could look at?

Answer 1

Here are techniques I use that work for our environment and may work for yours:

• Pair program / live code in the area of knowledge/code you are transferring if it is for an individual or perhaps a small group
• Prepare valid diagram of the code base's architecture and update what architectural documentation you currently have
• Have an overview of your applications technical layout memorized or readily available so that you can walk through the entirety of it with a whiteboard in an hour
• Know and more heavily document the problem areas. These are the tough parts of code you struggled with (and may still struggle with) that you now anyone else will also likely have issues
• Prepare a wiki where you can have light documentation and any information readily available so that you have a living repository of information handy for the new developers
• Brush up on all the code and areas of the code base that you likely forgot (anything 3 months old perhaps?)
• Be patient when explaining the code!

These are just some idea I have used. The one that I think really helps the most is being able to think through a whiteboard presentation that you can condense into an hour. The reason I say this is it forces you to know the larger pieces of the code/architecture and it will almost by default highlight some of the difficult to understand areas. Once you prepare that it becomes the starting point for initial knowledge transfer discussions with new developers. You will need this as a place to start.

From there you can go into the tasty bits of the code and flesh those area discussions out. For example we have a tough Data Replication area of code between ERPs and this can be difficult to understand so we have a series of presentations and discussions prepared to go down with new developers. Both self directed information and detailed live presentation.

In the end nothing beats out sitting with the developer and working with them in the tough areas. The tough areas will be different depending on the developer you are working with so this live coding and walk through often highlights those areas as you do it and allows you to adjust on the fly.

Code is itself the best documentation if you have been clear and consistent in following a good standard. With adequate documentation and a gentle nudge to the right areas in the code base most good developers will pick up on what you were doing or trying to do and formulate their own questions for you to answer. This is where brushing up on the foundational aspects of your architecture and code will help you be better prepared too.

In the end enjoy the process and have fun and be patient. Patience is key. Along with patience you should let your management know that they to will need to be patient. Knowledge transfer takes some time and in your case more so in that you have been the only developer on the application for years. There is a lot of knowledge to share so make sure they know this is not an overnight or even over a month only endeavor.