Offshore and Code Review

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…

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to Ma.gnoliaAdd to TechnoratiAdd to FurlAdd to Newsvine

4 thoughts on “Offshore and Code Review

  1. Hi Nick,

    I find this article to be very helpful. I do believe code review is very important in offshore development. Do you believe code review and auditing can be provided by a neutral 3rd party, bridging between buyer and vendor? If so, how should the 3rd party consultant position himself to bring both sides together?



  2. Very interesting point, frankly I have never tried it. My initial thought is that could be rather expensive (due to ramp up and domain knowledge issues), but setting that aside seems like a very interesting idea. To some degree it is very similar to what is commonly done by larger organizations that can afford groups dedicated to quality and processes… A third party dedicated to code review can be very successful assuming that people involved are experts in both technology and diplomacy (rare combination i have to admit). it would be especially difficult to stay Switzerland when one of the coders come from offshore; too much politics and tension to begin with. … Very interesting – I will check with some of my friends if they have any real experience in the process, will blog if i find something interesting. Thank you, Nick

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s