When Moving a Code Base, Bug Fixing Makes a Good Start

Two of our projects involved taking a large (hundreds of thousands of lines of code) code base and moving substantial development of the code base to the Bangalore lab. In both of these projects the Indian team began with a few iterations of bug fixing before they started adding new functionality.

Starting with bug fixes allowed the Indian team to become familiar with the code base, before they did substantial work on it, since bug fixes involve more code reading than changing. Although this worked well, there is some concern that more experienced people may consider it to be a stigma to be doing only bug fixes. While some people may perceive this as a problem I believe that working on bug fixes or very localized feature changes is one of the best ways to get familiar with a large new code base.

The nature of communication of bug fixing can also make it an easier activity to work with offshore. Onshore teams can spend their day mapping out details of bugs, which can be communicated to the offshore team and worked on during the onshore night. The onshore team can then review the fixes the next day. I must stress that this is not more efficient than having an on-site team fix the bugs, due to the communication difficulty, but it can be a less complicated way of working with an offshore team.