What are off-shore resources' experiences like working for foreign companies? [closed]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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

Bad:

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.

Good:

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.