Let me first start out with two process notes…

1) It’s hard to get an article like this published on the Internet because of the substantial amount of web traffic which is coming from off shore.  That’s why this is a blog post.
2) I have the GREATEST respect for many folks who happen to be outside the US.  This isn’t an attack on the idea in general — it’s an open conversation (albeit one sided) about some of the ways that outsourcing costs more and no one can see it.

First, as I’m preparing to push for my new commerce web site (softwarewishingwell.com) I’m seriously looking for being as efficient as possible.  That means the review of techniques and thinking that I’ve been doing, but it also means looking at how to acquire the construction resources I need.  (I’ll be doing most of what represents requirements and design myself — in whatever form it takes.)  I’ve found a few different options for getting the construction done — and they look like they’ll be a great way to keep my costs down.  However, I’ve also seen first hand how off-shoring can fail to work.  Here are a few warning signs that I think many organizations miss…

1) The off-shore resources aren’t following coding standards (or you don’t have coding standards).  This just means tons of rework with no hope of any escape.
2) The off-shore team doesn’t receive any training of any kind.  You don’t coach them on how to develop software better.  You figure that they’re contractors and you shouldn’t waste your time on training people who aren’t on your staff.  The fallacy with this idea is that you don’t realize how much cost you’ll incur between the time you identifiy they need the training and the end of YOUR project.
3) You’re noticing a high defect rate.  Of course, you’ld have to actually track defect rates and associate them to the code that caused them (which many organizations fail to do).  If you did you might notice that a disproportionate number of your defects are coming from off-shore.
4) You’re having to define things in such detail that you feel like you’re spending more time specifying the code than it would take to write it (and you’re not getting what you asked for.)  If you can write it faster than it takes you to write the specification… then you might want to just write the code.

Most people ignore the warning signs above because they don’t measure the right things, they’re oblivious, or they simply don’t want to hear it.

Remember that finding a defect late in the process can cost 100 times as much as fixing it quickly.  The fewer repeatable defects you’re fixing the more likely you are to find the important defects that might slip through.

A final note, both traditional plan-based development and agile development work better with better developers.  Agile is particularly sensitive to having good developers.  If you’re not helping your developers become better, you’re shooting yourself in the foot.