Offshoring software development has been a popular option to consider for reducing costs when building an application. Various countries have well-trained developers who are willing to work much cheaper than American developers, and with English being the most common second language in the world (and the international language of business), the developers of these nations are very tempting to American management. As an American developer I’ve worked with companies that have offshored projects as well as developers from several countries, and even had my own job outsourced. I’ve noticed several pitfalls in offshoring.
The first, and most obvious, is managerial oversight. When the developers are six time zones away there are extra burdens placed on the project manager just in communication; when you’re writing instructions or specifications you have to be far more thorough than you would if the developers were in the next room. Managers are used to interacting face to face; a conversational approach to dealing with questions as they arise refines and defines the project much faster than written communication that can’t be responded to for 24 hours. Good communication is key to successful management, and the impaired communication caused by sheer distance often has the project manager operating on faith.
In the same vein as oversight, quality control is another pitfall. Quality control is, and must always be, done locally. Project parts from offshore can’t be tested by the local project team until they are delivered, typically near the end of the project phase. This frequently allows less time for thorough testing compared to the locally developed parts that had been tested and corrected during the development cycle. End-of-phase testing is a poor time to discover a misunderstanding in the requirements. Additionally, every development shop has its own coding standards to support and enforce the consistency and quality of application development. Offshore developers have their own standards (one hopes) and those standards are not likely to match those of the hiring company.
A pitfall that many people don’t expect is the effect of culture on coding style; the way an application is structured internally is greatly influenced by the culture of the people writing it. One example of this is the idea of “clean code.” In America, clean code means that the code is readable and concise with a general adherence to coding principles (we’re willing to bend the rules from time to time, but we swear that we only use our powers for good). In India the term clean code has a completely different meaning; the concept of “clean” has deeply important connotations in Indian society and religion and clean code to an Indian developer means complete and absolute adherence to all coding standards and principles. On one project I was a part of the code written by Indian developers was incredibly difficult for American developers to support: a single procedure/method would consist of a single statement of over 100 lines of code—a nightmare of nested “IF” statements designed to comply with the “single exit point” general coding principle. For non-developers, imagine reading a book in which the author writes two-page sentences. The time spent deciphering an overly complex structure would have been better spent on other aspects of the project.
Extra help on a project is nice to have, but offshoring software development is a risky proposition. I’ve seen projects encounter significant delays for the silliest reasons: misunderstanding a written communication because it lacked the nuance of a verbal discussion, adherence to inappropriate rules that should have been bypassed, and cultural conflicts between American project managers and foreign developers (and between American and foreign developers). Hopefully, the trend of offshoring development will decline; while it’s a way to cut software costs, it’s often a case of getting what you pay for.