Currently I am handing over my ongoing iOS project to my replacement guy. This is the first time I am handing over my work to any buddy. So I was under little pressure of how can I make sure that he will understand almost every thing I built in this project. I was planning my handover module wise, feature wise, classes wise, etc but I ended up handing over project by pair programming!
This was not at all planned but it happened to be in this way. Two three weeks before arriving replacement guy I stopped implementing new features and started refactoring my code. While refactoring I found that my application code and back end services code was very tightly coupled and that should anyhow be get decoupled. So I started putting interfaces between services and application, using protocols. By the time this guy arrived and I was in the middle of refactoring. Instead of explaining him existing working, coupled code, I continued refactoring the code while this guy was sitting next to me and carefully watching what I was doing.
Then after spending around one week like this he started getting good idea of existing code and new proposed refactoring. Then he started telling me ways to decouple code, and then he started actually refactoring slowly. Then we both started planning refactoring and cleaning code. Now I am sitting next to him and watching him refactoring the existing code; 😊
I think now that he is getting better idea of existing code also and newly re-factored code also. What do you guys think of this approach of handing over projects by pair programming? Please feel free to criticize my approach and leave your opinions and suggestions below; thanks!
Top comments (6)
I think this is a great approach.
How much time has been scheduled for the hand over? Seeing as they have to pay two people for some time.
This is an interesting question. The idea that is lingering behind it, insinuates that pair programming quickly becomes too expensive. While it may be expensive indeed, I do think it is one of the best ways to hand over some codebase.
Currently I am in the process of handing over a project. I will leave the client who has chosen to oursource all development. Problem is that there is no planned overlap, so all my handover must be done in the form of documentation. Problem there is that there is no feedback. If my way of documenting is not clear enough for my successors, there is no way to correct this. If I document things they already know, it is a waste of time, if I don't document enough I will leave them in the dark. Both with - again - no way to correct.
Doing pair programming gives you the chance to correct things like that. Sure I wish I could do some PP with the new guys.
Of course it is a great opportunity - and I did intend to talk about the costs of pair programming in general.
But in this case they really have to pay two people (assuming one is a new hire and the other is leaving) and its great they even allowed for some overlap - which I would have not really expected.
Its just around 3 weeks! I think its enough, isn’t it?
I think this is practical. Two minds are better than one.