Like many companies, we operate the "offshore model" whereby the bulk of our development team is comprised of developers contracted to us from abroad where relative currency strength works in our favour. India is the most common choice. This model makes a lot of sense for two reasons:
1. As work waxes and wanes, or if times get hard and the team needs to be downsized, the number of people offshore can be increased or reduced easily, and without recruiting or losing permanent members of staff.
2. It's cheap.
However, for me, this model poses two fundamental problems as well; one directly, and one indirectly.
1. Working with developers who aren't in the same office as you is hard. Working with people who aren't in the same time zone as you is even harder. And collaborating with people whose first language isn't English (often on a poor phone line) makes it harder still.
I believe that the impact on productivity [1] caused by these things risks outweighing the financial benefit.
2. Usually there's not much of a recruitment process involved; rarely even a coding test or technical interview. Managers ask the offshore company for another 5 "resources", and on Monday morning there they are on the end of the crackly phone line. However, the offshore team you accrue often have less than a year or two's development experience.
Now don't misunderstand me, I have no issue with junior developers (I was one after all), but I believe that junior developers need support and development - precisely the sort that is usually denied to offshore contractors: training, educational sessions, mentoring and so on. They are often denied access to the business and therefore an understanding of the problem domain and context they're working within.
Considering all of the above, it should come as no surprise that the quality of their output isn't always up to scratch.
However it does come as a surprise to managers when code quality decreases, and team efficiency and morale slowly decays. They never say: "perhaps it's the fact that a large number of the team [perhaps even the majority] are geographically disconnected and not very experienced".
Why not?
The answer lies in one of the great myths of software development: Your team should consist of Designers and Coders.
This is how the myth goes:
The Designers are the permanent, onshore, team. They have the knowledge of the business, and are usually more experienced and (hopefully) have time and money invested in their development. They're the "intellectual capital". They may even be flattered into thinking that they should move away from the daily grind of actually cutting code as that's beneath them. After all, they do Design with a capital D.
The Coders on the other hand are ten a penny, and can be less skilled - after all, all they do is write the code, and implement the design which the Designer came up with. Practically anyone could do that.
Right?
Well my opinion is: Wrong. Absolutely wrong. And here's why: Coding is design. [2]
Almost every line of code I write involves a design decision: Do I use an instance variable or a local variable? Do I make this component request-scoped or globally-scoped? Do I hold this data in a Map or a List?
All these decisions add up to create code which is more or less extensible, performant, resilient, secure, maintainable and so on - and almost all of these decisions are too detailed to be made by the Designer. (Having said that, every now and then you do meet a Designer - who may also call himself an Architect - who creates designs to this level of detail. In my experience these designs are almost as large as the code itself, unwieldy*, and probably full of oversights and mistakes which only become apparent when you actually cut the code).
(* As Martin Fowler [3] points out: For diagrams, comprehensiveness is the enemy of comprehensibility.)
So what does this mean?
It means you should get your experienced developers to write code. They should be both Designer and Coder - with no distinction drawn between the roles.
Let me give you a scenario I've experienced, and seen, many many times.
Working as the Designer, I produce a documented design and go through it with the Coders. The Coders are fairly junior, so this process takes a while.
A few days later I ask to see the code, or I get a code review request. When I look at it, I see that their interpretation of the design isn't exactly how I imagined it.
For some things I can clearly explain to them why the way they've done it is problematic, and I ask them to change it.
But some things are less easy to justify. I know it's not how I would have done it, but it's getting late in the project to refactor things. It seems to work okay - so I say "you know what, just leave it as it is - it's probably fine."
When a production issue occurs three weeks later I realise why it should have been done the way I instinctively thought it should be done.
Sometimes it's not a production issue, but we suddenly need to extend the functionality in a new way which the implementation makes more difficult - but funnily enough if it had been implemented the way I would have done it - had I been the Coder and not just the Designer - it would have been easy to extend in this new way.
A variation on the above is that the experienced developer (the Designer) is so thinly spread that she actually finds she doesn't have time to review all the code the junior developers (the Coders) have produced. This makes issues with the low level design even more likely - and when the production issue occurs, the Designer looks at the code and exclaims "WTF!?" (which means What Terrible Foolishness!)
So on the off-chance you're a manager with the authority to control how your development team is managed and resourced, try giving quality a fighting chance. Abandon the offshore model and give your permanent team everything they need to do their jobs well.
You'll be amazed at the difference it makes.
References:
[1] Zenun et al: The Effects of Teams' Co-location on Project Performance http://extras.springer.com/2007/978-1-84628-975-0/col/dpi.inpe.br/ce@80/2007/01.22.18.46/doc/paper.pdf
[2] The reader who can tell me who first said this wins a Cadbury's Fudge, because I can't find this reference anywhere. It was probably Kent Beck, Ken Auer or Roy Miller.
[3] Fowler, Martin: Is Design Dead?, http://martinfowler.com/articles/designDead.html
