Does off-shore resourcing work? [duplicate]

Question

Possible Duplicate:
Offshoring: does it ever work?

Do you or your company use off-shore resources for coding?? Has it been a successful experience? What was good about it? What was bad?

Answer 1

My company does, and it's a mess and a half. We've got a Ukranian offshore team that, to simplify things a little, takes care of a lot of the "grunt work" of coding, while our real team does the "craftsman work."

Theoretically, that's a pretty good setup. In practice, it's a disaster, because even boring, mostly repetitive tasks are only mostly repetitive, and they have a nasty habit of having little details that need to be paid attention to hidden somewhere in the middle of the batch. This is the sort of thing that our beloved Elbonian Code Monkey Squad invariably gets completely wrong, and then we end up having to waste time fixing their mistakes.

The higher-ups hired an offshore team "to save money," but in the end it ends up looking a lot like the depressingly common Standard Business Mistake that ended up screwing up our whole economy a few years back: focus exclusively on saving money in the short-term, because that's all that people watching the money notice.

My advice on offshoring: don't. You get what you pay for.

Answer 2

From my observations of having worked with two different off-shore teams over the years:

• It's hard to interview people from thousand miles away.
  It's not just that it's difficult to interview via skype and mail. You're paying a fixed amount per programmer per month to an intermediary, and in both cases I've experienced the intermediary's financial incentives ran counter to what we needed. The more programmers he can get us to need for the same work, the better. The cheaper the programmers he can hire for the same job, the better.
• Insufficient knowledge of the english language
  I get mails that clearly came from google translate on a regular basis, despite a supposedly "excellent" knowledge of english.
• It takes a long time to get people worked in
  There's the language barrier, and there's the fact that you're doing stuff across skype, mail and chat. Actually sitting down with someone really speeds things up. All the hours spent teaching are hours counted double, once off-shore and once in-house. This is very expensive time.
• It is difficult to get them to understand exactly what you need
  The in-house people end up spending a lot of time writing specs instead of building software. Our best programmers spend their days writing word documents and e-mails. It's a shame.
• You never know what the problem is
  When a feature is late or badly coded, it's never obvious where the problem is at. Is the person not worked in enough? Was the spec not good enough? Was the spec not explained well enough? Is the person actually doing the work, and not just looking at squirrels all day long? Is the person actually competent at programming? You're a thousand miles away, and it's (almost) impossible to figure out what's going wrong.

My experiences have led me to conclude that off-shoring just the coding is a bad idea. Off-shoring the whole business, that works. Off-shoring testing, that works well also (I have excellent experiences with that). But shipping a spec to a different continent to have it coded up? At best it's a break-even, at least in my experience.

Answer 3

The short answer is that if you do this solely in order to reduce costs by delegating all the shitty work outside, then you're already screwed. On the other hand off-shoring can deliver brilliant results when you treat the other side as a partner, not a cheap work force.

• Hire a skilled team that is able to work independently. This definitely won't be the cheapest one, but you'll save some money anyway on the difference of wages between countries.
• Assign well defined sub-projects to the teams. Schedule daily meetings and weekly reviews, but avoid the temptation to micro-manage. Delegate the responsibility for the project with adequate amount of authority. Try not to be the bottleneck, only then the process can scale and bring real value.
• Build a trust between the teams. Start with a simple project that is not critical to your operations. Once the team delivers, start rising the bar. If you are satisfied with the results, stick to the same team even if somebody else offers you "a bargain". In contrary to the common opinion off-shoring programmers are not interchangeable resources.

Answer 4

I worked for a company that tried to outsource a major component of a particular project that was export controlled. This meant that the third party could not, by US law, test their component against the rest of the product because the software wasn't allowed to leave the country. Instead they had a "simulator" for our product. You can imagine how that went. The phrase "it works in the simulator!" became the new "it works on my machine!"

We did have a little PDA app get outsourced, and it worked out well. It wasn't the most usable thing in the world but it worked well enough. It was probably a good decision. But the above example was a disaster. We had to take off one of our best programmers to rewrite the entire component. It literally did not work at all. We ended up spending a ton of money either using our own man hours to fix outsourced problems or flying in and putting up the outsourced programmers to work for a month at a time. Both were crazy expensive and we'd have been better off just doing it ourselves.

Answer 5

My answer from stackoverflow, updated.

Most out-sourced software development ends up with a product that is late, over budget and delivered without all the agreed upon features. As we all know, this never happens with in-house software development.

With that said, the only out sourced system that I've seen actually work well was one that was a reverse engineering web port. Two old clunky vb6/sybase apps we updated screen-by-screen report-by-report to ASP.NET backed by SQL Server 2k. The out source firm did this on time and almost on budget. My involvement was to listen in on the bi-weekly status phone call where they would request clarification and we would agree to send screen shots and supporting documents.

Management considered this project was a success. After spending a boat load of money, the clunky vb6 app with a dated UI and antiquated feature set that no one knew how to support was replaced with a clunky web app with a dated UI and antiquated feature set that no one knew how to support. Mission accomplished, since the goal was port the app and not make the app better.

Management clearly saw this as an investment in app porting, not people or process or knowledge development. If the same time and money had been spent in-house, the results might have been a flop. Or they might have resulted in a less clunky app with a feature set that better supported the business. But this would require people to talk about what the app does rather than how the app runs. It might require much more involvement from the users. It might even require trusting the developers on what might be changed. This is nearly impossible when the programmers are out of sight and out of mind, never seen by management let alone able to interact with the users.

The moral of the story is that defective management tends to enforce defective processes which yield defective results. Having the team far away from management makes it all the more difficult to notice bad processes and the improper management that causes it.

Answer 6

I am sure that to the higher-ups, it's a worthwhile exercise. There are tax write-offs and other business incentives provided by the government, no health benefits or workman's compensation insurance as there would be for full-time employees, and just a lot less responsibility overall for the employer. Offshore arrangements can be quickly made or terminated as the business contracts that they are, without lawsuits for "age-ism" or discrimination, etc.

I am also sure that to the developers and mid-to-low-level managers that work in those companies alongside or in direction of those off-shore resources, it's only an exercise in frustration. They never get it right on the first try, they never understand the business need or the context of any request, and they never just do what they're told. It is just about guaranteed that an on-shore resource will have to be involved to re-mediate their mistakes or spend too much time relaying issues. It is frustrating and maddening at times, and it's something I would never do to my employees (if I were an employer.)

Answer 7

I have had teams overseas for years and have a side business providing those services to others. Big stuff like our core columnar database product and smaller projects like narrow function iPhone apps, etc.

Outsourcing is great for component work, back end work or smaller projects. If you have a big project that is the core product of your company, you need to think carefully about outsourcing, at least the portions that are integral to the product goals. Projects can fail for a number of reasons, but when it comes to outsourcing one of the biggest problems is coordination and buy in from the "home staff". Often a home staff team member is put in charge of the outsourcing team, and they really have no clue how to manage this resource - or they simply do not want to do it and can passively sabotage it.

Outsourcing will eliminate many low end coders, much like scanning and self bagging did away with bag boys at the super market. But developers who have a keen understanding of a complex product as the company envisions it must be close to management. That means at least a slight reduction of positions but also more competitive and more profitable positions in the home staff.