I have had many opportunities to work with developers outside the United States in a variety of capacities. To begin with, let me assure readers that there are great developers all over the world. The sun never sets on the current team I work with. The great thing about software development is that you can find great talent wherever the Internet is.

There are great individual developers in every country, but I have found that, in many countries, the culture of software development has not evolved to where it is in America. When hiring individual developers, this rarely matters. The proper developers tend to gravitate to whatever level you are hiring at (or, alternatively, you can have a headhunter screen applicants to make sure only the most qualified apply).

However, it is easy to get bitten by this difference in developer culture when dealing with outsourcing companies. The composition of talent in the outsourcing company often reflects the general developer culture of the country that the company is from. Therefore, although an outsourcing company may advertise highly-skilled, experienced developers at a low price, it is difficult to know if the developer culture they are coming from matches what you would expect from a developer team in the United States.

Technical ability is not the concern. In fact, I would say that many of these countries have technical knowledge that surpasses that of the developer culture of the US. However, successful outsourcing is not dependent solely on technical knowledge.

There are two primary areas of concern when dealing with outsourcing companies. The first is that many of their developers will build exactly what you tell them to build. You might be wondering, “What’s wrong with that? Isn’t that what we want?” One of the most important skills in software, however, is for developers to be able to recognize when the specification itself is the problem. More often than not, specifications that are handed to developers are either incomplete or wrong in some fundamental fashion. This means that developers will often have to “do what you mean” but not what you said. Sometimes, even doing what is meant is the wrong thing. Good developers will recognize when a company isn’t properly recognizing the role or abilities of technology. Sometimes they will rely too much on technology, sometimes too little. In any case, a good developer will push back on this. The specification is a starting point, not a command from on high.

Developers from outsourcing companies, however, oftentimes use the specification as if it were an unchangeable document. They will implement precisely what it says to the minutest detail, even if it makes no sense. They often won’t even tell you that what you are asking for doesn’t make sense — they will just deliver what was requested. This can waste a large amount of time and resources as everything is tested and the specification is revised and sent back to the developers to develop again. Note that the people revising the specification are not the developers, but rather those hiring the outsourcing crew, who often are outsourcing precisely because they don’t have the technical skills to make a correct specification.

The second area of concern in outsourcing doesn’t deal directly with how the code works, but rather how easy it is to maintain. I have found that many outsourcing organizations don’t properly modularize their code. One of the fundamental concepts of programming is the DRY principle — “don’t repeat yourself.” If you find lots of repetitive code popping up, you probably need to rethink how it is structured. 

Imagine that you want a slightly different email sent out in different situations. The email is 90% similar, but has one block of text which changes in every email. A good way to program this would be to have a function that generates the email, and receives that extra block of text as a parameter. That way, if the boilerplate changes, you only have to change it in one place. I have found that many outsourcing organizations will not modularize in this way. Instead, they will have separate functions for each email sent out that has the boilerplate copied in. This means that every change to the boilerplate means a change to all the emailing functions and not just one.

This winds up being an issue more often on the technical side of the code than in anything that a user sees. However, what it means is that, long-term, the code costs more to maintain, because not only do changes have to be made in multiple places even when it seems like it should be a single change, but the same bug pops up over and over again in each place where the code is copied.

While these issues can be associated with any developer or any contract firm, I’ve found that, in general, it most correlates with countries that have technology training without a solid developer culture. I imagine that as development efforts expand, the developer cultures of the different countries will normalize, and we will see less disparity from country to country.

In any case, if you do decide to outsource development work, these are the issues that I have found cause the most problems. Having your specifications double-checked by a programmer before sending them out to be sure that they are solid will help mitigate some of the biggest problems. Additionally, specifically ask the outsourcing firm to take advantage of opportunities for modularization and request architecture diagrams to put those ideas in the front of their minds so they are thinking about it more than they normally would.

While outsourcing can be beneficial, be aware of gaps between the developer cultures of different countries and how that impacts your interaction with them.