How to benefit from offshore programming

How many writers does it take to write a great book? Would hiring two semi-illiterate writers help a Pulitzer Prize winning author write a better book faster?

These questions may sound silly, but only until you realize how many customers come to offshore labor marketplaces like Upwork.com or Freelancer.com with cost saving as their #1 priority and fall into one of the two traps:

– trying to hire overseas coders of the same class as they saw onshore but at 25%-40% of the onshore rate;

– trying to hire x2-3 more coders offshore within the onshore budget.

In most cases this would lead to failures, even subsequent within the same project, due to the two reasons described below. These failures undermine the reputation of offshore outsourcing, usually for a fallacious reason: communication. But in most cases communication issues are just a symptom, while the true reasons are lying deeper.

1. The skill-to-production curve for various occupations is different, and for programming it is stunningly non-linear. It’s a well-known phenomenon that a great coder may end up being an order of magnitude more productive than his mid-level counterparts. And buying x times more coders doesn’t mean you get things done x times faster – this would only mean you are buying x times more code, which, at best, is just a wrong metric to be looking at.

2. Great coders are not only fewer than average ones – they are much less active at the offshore labor sites, as they are usually packed with well-paid work. This greatly diminishes the chances of finding a great team as you lower your rates, especially if you rely primarily on the passive search, like posting a job and considering mainly incoming offers as opposed to searching yourself, whiсh many customers fail to do after they get overwhelmed with droves of cheap offers.

These two issues together can easily result in hiring a twice as cheaper coder with 3-4 times lower efficiency who will be producing unscalable and buggy code, which may triple your initial project costs, and, as the system further develops, constant bugfixing and refactoring will be taking more time and money than implementation of new functionality.

A mistake often made trying to contain the problem is hiring an experienced teamlead to supervise the team of low-class coders. Apart from doubling the cost of the team, it usually doesn’t do much, as the gap in class still crushes productivity.

In successful projects, going offshore for programming is never about just more/cheaper – it is always about better: completing tasks with less amount of code, with fewer bugs, with better analytics resulting in better UX and less reworks and less time-to-market for the product. Lower offshore rates result in a lower budget only provided that you are strongly focused on raising the skill level of your team as your #1 priority. This is what will save you money.

Here are a few small tips that will help you succeed:

1. Have a test task with known implementation time, and ask for estimate from your new team member – this way you will filter out those who are slow or overprice by overestimating implementation time.

2. Work only with teams that have 100% job success rate and excellent testimonials for large projects. Don’t settle for lower success rate, and ignore testimonials for short projects, as they will not be representative.

3. Stick with teams with strong analytical expertise, those who strive to understand your business and how exactly the product features and processes you are ordering will help you reach your business goals, as blunt coding of poorly specifed system based on vague understanding of customer’s underlying expectations may cause reworks that might double or triple the costs and length of the project.

4. If possible, hire a trusted expert who would be assessing new team members and, if budget allows, occasionally review their code.

Go offshore: a great remote programmer is better than an average local one. And as long as you focus on the class of your team, communication will never be an issue.