Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Are you an off-shore coding resource for a foreign company? What are the challenges of working with foreign companies? What helps make the project more successful?

share|improve this question

closed as off topic by Anna Lear Sep 29 '11 at 4:15

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

I would love to hear someone's story from the other side of the equation. –  Ali Sep 16 '10 at 3:03
Someone please do the needful! –  Cade Roux Sep 16 '10 at 13:01
Well calling someone a "resource" highlights one of the major problems with out sourcing. –  ChrisF Sep 18 '10 at 15:11
Calling a person a "resource", whether they're employed directly or off-shore, implies that they are interchangeable with (almost) any other person and that their skills, needs etc. aren't important. It effectively de-humanises them. It makes it easier to fire them (sorry "let them go"), and ignores their domain knowledge - which is vitally important to them being successful developers. –  ChrisF Sep 19 '10 at 11:51
@Xepoch - I wasn't suggesting that interchangeable was the opposite of irreplaceable. Everyone is replaceable, but there is always a cost - even if it's kept to a minimum. Using the word "resource" implies (to me) that someone somewhere hasn't taken that cost into account. –  ChrisF Sep 19 '10 at 20:51

3 Answers 3

up vote 8 down vote accepted

I've been at both ends of the off-shore model, and my experience with it have been "not so good".

Feeling of ownership/responsibility or the lack of it, I thought, was the key.

When you are the off-shored resource, in a "typical" environment, you will not be given the "bigger" picture and chances are you will never ever meet the client (end user). Decisions will be made for you, and all that is expected from you is to write code. This would have been fine, if the code by itself was super exciting, but in most cases its the "business" that makes things interesting, not pushing data in and out of ORMs. When requirements get messed up (which you as a developer had no say in) you are expected to bear the brunt and rewrite stuff, may be even work longer hours that day. When things go fine, you get an email that reads - "thank you for your hard work and support". It is no mystery that you eventually lose interest in the well-being of the project and its success or failure mean little to you. When this happens you get bad code.

When you are working with off-shored resources and are having a not-so-good experience, either what I stated above is happening where good programmers have lost interest, OR you didn't choose good programmers. If you believe that your off-shore project manager will choose the smartest and brightest resources for your project, you are mistaken. He has other things to consider, he has to put together a team quickly, he has to deal with high attrition rates, etc. Finding good programmers is in his list, but not at the top of his list. Always interview the off-shore resource you are going to work with.

I feel, the closer you are to the client, the more interested you are in the success of the project.

If teams were geometric shapes, the client should be at the center of the circle and the team members should make up the circumference. In an off-shore model this figure is generally a line, with the client at one end and the developer at the another, both having zero visibility of each other.

share|improve this answer
+1 Awesome feedback. –  Walter Sep 21 '10 at 16:01

I live in the US and worked for a foreign company. Technically they had US offices but the division we worked with was solely in Europe.

Language barrier is obvious and was mostly handled on their end since they knew English. After working with them for a little while, the accent was easy to understand.

Culture barrier was interesting. They take off a lot of the summer, but since we're still working, it's somewhat demoralizing (and hard to get answers to questions).

Lastly, we met in person every 6 months or so (either us going there or them coming here). Really, this was vital to getting on the same page. We did a lot through desktop sharing and over the phone and email, but sometimes it takes an in-person meeting.

share|improve this answer
Aaah, the joy of state mandated minimum 5 weeks vacation ;) –  Bartek Tatkowski Sep 21 '10 at 12:01

The language barrier will be the first hurdle i.e. the accents take getting used to on both sides.


There is a tendency to do all the design work onshore and send over word documents (or low level designs) for the offshore team to code. This means trouble and leads to clarification calls on a regular basis. On top of that, you're likely to meet those who "code by google" or "plz-send-me-the-codes". Most of them frequent SO as well I guess.


What we had in our company is daily stand up calls with both onsite and offshore teams. This builds a sense of common ownership for the project, rather than an "Us v Them" mentality.

Over a period of time, the onsite team get more comfortable delegating independent modules or say the maven build process offshore. Provided there is a review mechanism in place, this works out quite fine for all.

Also our specific coding environment was TDD which means the reviewing team can see the daily build reports for code checked-in, along with unit tests, findbugs reports, lint4j reports etc (all for java). So this also helps in seeing what the guys are up to, rather than a Waterfall-based Failure at the time of testing.

share|improve this answer

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