Code review is a rather controversial subject. On one hand many SDLC gurus, tech leads, and architects agree that it could present an incredible value, on the other hand it’s one of the last quality procedures to be exercised in a majority of organizations. There are many reasons code review often takes the back seat, one of the most important ones is morale impact of code review. If let unmanaged code reviews can often cause tension in the team, things quickly become personal and instead of improving quality of code generate turmoil and finger pointing. Another reason of code reviews’ lack of popularity is their complexity in process sense, in particular timing.
I am in general a big proponent of code reviews and when it comes to offshore I found those irreplaceable. Specific implementation of code review depends largely on SDLC and outsourcing model used by the team.
If you fully outsourced your SDLC to an offshore partner you in a large degree will be at mercy of their internal SDLC. If you have an ability to influence your vendor’s processes you may want to request code review as a mandatory step and hope that it will be performed according to the best practices that are generally well known nowadays.
If you are retaining a portion of SDLC in your organization code reviews would be great candidates for components to be kept internally. I saw a few “best” practices in implementation of code reviews with offshore development teams that were rather successful:
- Full / high percentage code review of the code by a senior on-site team member. S/he is typically assigned as a tech lead of the team and is in general responsible for technical integrity of the deliverables. S/he reviews (or produces) all high level architecture and technical design artifacts, and then reviews code produced by offshore developers. This model works particular well in waterfall models, with some modification it can be applied in more agile SDLC as well. There are obvious scale, morale and org issues with the model, most of them could be dealt with if tech lead(s) bought in the process and are qualified for the role.
- Using code review tools that help facilitate and manage the process. My team has been using Cruicible with an offshore partner in Brazil with a large degree of success. By the way one of the measures of success could be the sustenance of the process: if dev team is using code review without constant nagging and pushing rest assured that code review is working out for you.
- Spot check with follow up process could be rather efficient method of enforcing some specific development practices, e.g. coding standards. The idea is quite simple – if the code review reveals specific issue you need to follow up with the developer, after a little while you need to code review other newer artifacts and see whether the problem is addressed. When offshore resources are in ample supply I would exercise the rule of three – first time it’s your fault, second time it’s my fault, and there is no third time… Random spot check style of code review also offers great help in identifying skill / knowledge gaps and IQ issues.
In general code review only applies to organizations with a very high bar for code quality. And the bar should be held high for everyone independently of their location. Producing high quality code is not easy and it doesn’t happen by itself, it is quickly deteriorates if left alone. As one of my readers said – people do what you inspect not what you expect. In that light code reviews or code inspections play tremendously important role. Inspections by themselves are still not sufficient and must be supplemented with broad draconian measures of code quality that apply across organization. It is a matter of personal preference whether you use the rule of three or much softer measures, independently it is exceptionally important to link code quality to individual and individual performance appraisal.
I have to mention one rather controversial and very important point – high quality of code could be a luxury an organization could not afford, even more – in some cases it is an unnecessary extravagance. In today’s world producing code that doesn’t pass high standards is not at all as detrimental as it used to be in the days of PL/1 and C++ and even more so in the days of low performing hardware and memory limitations.
I remember having a long discussion with one of code quality evangelists – he was going on and on ad infinitum about how important is to write one beautiful line of code instead of three ugly ones. Very articulate and passionate about the topic he was impossible to win over especially considering my pragmatic and not so elegant position. We parted both even more firm with our original viewpoints.
When it comes to offshore it becomes even more important not to try to enforce quality of code that is above reasonable expectations. It is difficult to find high quality code producers even in this country with plenty of evangelists around. BTW, even the guy I mentioned before wan not fault free and left plenty of debris behind. So pick you battles wisely…