Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

This question already has an answer here:

These days one only gets to hear the anti-outsourcing argument citing failed projects, lost jobs, cultural differences, communication issues and so on. The success stories, cost savings, shared cultural experiences often get conveniently ignored.

What can programmers from both sides of the globe do as a community to improve the way outsourcing works and to make it more meaningful and relevant?

Please suggest constructive ideas/experiences rather than letting this be another opportunity for ranting.

share|improve this question

marked as duplicate by gnat, GlenH7, Corbin March, MichaelT, mattnz Aug 23 '13 at 3:48

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

6 Answers 6

up vote 16 down vote accepted
  1. Make sure there are all possible means of comunication (phone, instant messengers, remote connectivity tools) available.
    A direct phone line to communicate, well, directly to someone, but also to make sure that the recipient does exist and did get the message. (An email with a return receipt is not an alternative)
    An instant messaging tool to communicate exactly what you are trying to communicate.
    Desktop sharing tool to make sure what you are seeing is what you are intended to see.

  2. Both the onshore and the offshore team should work on a common code base. Daily/Weekly code drop are a thing of the past.

  3. Be aware of the differences and prorities, cultural, and others.
    Here in India, many use 'Ok' to mean a state between yes and no. I have seen western clients taking this Ok as a Yes and this causing major issues in projects. Both the sides should understand the differences, especially the issues that would affect day to day activities.
    I have seen clients and the outsourcing companies conduct day long sessions to explain differences like many Indians eat using their hand (without fork/knife), red is considered lucky in China, and ignoring those differences that are important in daily work.
    Another example: For many in India, the work city is not their hometown. This means many would want to leave early on Friday so that they can stay with their family for the weekend.
    In the workcity the company provides transport to where they stay (during the week, in the work city) and this means of transport is generally a office bus. So you stay for 2 minutes more, you miss the bus. Plan for meetings during this period in advance. The person may be willing to stay for 2 more hours (and plan for an alternate means of transport, the 'next bus', a cab etc) but would not be willing to stay for 5 more mins. (You miss the bus by 5 mins, wait for the bus for next 1 hour is not very pleasant). If you dont get solid answers during this (generally 15 min) period, the person may be in a hurry to catch the bus.

  4. Many outsourcing employees are called consultants or specialists. But that does not mean they are from the sky. They are also normal human beings, and do the same miskates as other programmers (sometimes even more, due to a variety of reasons)

  5. The (technical) work environment in the oursourcing service company need not be the same as the clients. This can be as trivial as a minor version mismatch (tomcat 10.5.1 instead of tomcat 10.5.2), and as serious as different application servers altogether (weblogic vs websphere. why? probably because weblogic for development is free). This can be solved by having both the teams to connect to a common set of servers using remote tools.

  6. The (non-technical) work environment can be different between the onshore and offshore locations. The work environment can be noisy, insanely hot, furniture uncomfortable (or even broken). These impact productivity directly and more often than not you cannot do much about these. These should be taken into account while estimating and measuring productivity

  7. A thin onshore team from the outsourcing provider is essential. No matter how many remote tools you introduce, you cannot emulate the client company offshore. The reason is not just communication. If you work for a company, you cannot do much justice if you don't understand the DNA of the company. You understand the DNA only being part of the crowd, not via powerpoint presentations.

share|improve this answer
+1 for the common code base. – Larry Smithmier Sep 20 '10 at 13:35
+1 for comments from the other side of the fence. Maybe I should add my own experiences as well (I worked for an offshoring setup for 7-8 years). – Rahul Sep 21 '10 at 3:55
+1 for work city is not hometown, commuting issues – pramodc84 Sep 29 '10 at 8:17

It is all about communication. Defining the problem and acceptance criteria and accurately communicating them is the key. This leads to piece work or project work, but not a mix unless the contractors are senior people that you have worked with before and the problem is well understood by everyone involved. The main problems I have had in the past were when I didn't do a good enough job defining acceptance criteria. Always realize that There Is More Than One Way To Do It and provide sufficient direction or context to ensure that what you get meets your needs.

I am currently working in a fully remote development environment and constant communication is key.

share|improve this answer
+1. I agree communication is the key. – Geek Oct 15 '10 at 17:14

After 10 years of offshoring experience and interactions with hundred of people worldwide, I have only one advice:


The top reason of failures is communication, certainly not competence of offshore developers. Proper communication is your responsability. Be able to communicate with a different culture can't be learnt in books. You have to learn by communicating.

Offshoring is just great! You met with incredible people worldwide. World diversity and cultures is so amazing.

share|improve this answer
Good answer, I want to add Offshore teams are like your own teams. You cant lead anybody in this world without communicating with him. – Geek Oct 15 '10 at 17:15

Following Agile methodologies can be a good idea. You get working software every 2-3 weeks so you don't get a big surprise at the end. Agile also enforces strong communication, the developers can approach the client directly for questions etc. Other practices like TDD, Code coverage ensure that you get a good quality code that can be modified without the risk of breaking something.

share|improve this answer

I've been both a consultant and an in-house developer and I have to say the worst code I've ever seen was written by consultants. Despite their expert knowledge they lack something important - commitment to the company.

They don't care about how easy it is to maintain the code they wrote because they won't be the ones having to deal with it. I truly believe in promote from within and loyalty. Reward your in-house developers by letting them do the fun stuff instead of giving it to the consultants. Happy people are much more productive than those who are not challenged, bored, and dissatisfied.

share|improve this answer

From working with subcontractors and being one myself there are two things you need to do:

  1. Be explicit in your requirements. Never leave anything to assumption, even if it is so well known in the industry or obvious that it shouldn't need to be stated. This can be things like: no memory leaks, which language it will need to integrate with, performance criteria, etc.

    It's very frustrating for both of you when a requirement which was assumed is never stated until after the they attempt to deliver. "Oh you wrote it in Python? We assumed you'd hand us a library to ingrate with our C++ applications. We can't accept that."

  2. Test whatever they give you. Seriously. This isn't just about poorly written code. It tells you where their strengths lie. Some firms are amazing at UI layout but horrid at responsive software. Others are great with numerical accuracy but fail at designing for the future. It'll let you know if the firm sticks with the contract or expects to exceed. If they gold-plate. If it appears as if you didn't communicate your desires until later in the contract.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.