I've worked with company A on a number of interesting commercial products over the years. After months of trying to find more good engineers in the local area, they recently decided to start working with an offshore consulting company.
We interviewed potential consultants for the project using screen sharing software and asked them to write code. The ones who passed started working on features for the next version of the product. They participate in daily stand up calls with the team here, and someone from here travels halfway around the world to work there every few months.
Result: Quality software delivered with every iteration.
Company B called me when they started having problems with an application built entirely offshore. I was told an executive visited the team once and he thought the demo was marvelous.
Result: There is a mythical beast in the ASP.NET world known as the "2,000 line Page_Load method". I never thought I'd see one first hand, but when I reviewed this code base I discovered an entire colony. The beasts live inside of houses built with #regions, and in the next village is an entire flock of monsters known as the "stored procedures using cursors inside triple nested loops". There isn't much land separating the beasts from the monsters, but there is a copy and paste river filled with fish we call "Execute method with switch and typecasts". The code is spectacular, and by spectacular I mean hair-raising.
If you go offshore to find talent, you might find success.
If you go offshore to find cost savings, you might find the iron triangle will tighten around your neck like a noose.
Comments
Remember for every business case i favour of outshoring I could produce a business case that completely contradicts that including the financials
I had the first offshore company developer come to the UK to show him Project 1. His was a well manner and pleasant, courteous chap, bristling with an MCAD. He had a very strong accent that was sometimes hard to decipher. But we got by and got on with the work in hand... One of the first jobs was to review the design docs, the code and where I was currently working in the code. I had a bug to work out (a tweak on a RegEx, that data into a class and pass it as a parameter to the middle tier, everyday stuff really) Devloper 1 said yeah no problem, so I handed that part over and continued winding up another area of the code. The change should have taken more that, perhaps an two (three at most even with an MCAD) a day and a bit later I was surprised that it hadn’t been done. So, I lent a hand. Only to find the code I remembered was no longer there, something else about 10 times longer and plenty of Ifs Thens and Elses... was in its place. Anyway about half an hour later after putting back my code (good old VSS) we, (I)got it to work. Well, you would have thought that he had scored the deciding goal in the World Cup Final!
Anyway, there is also a culture difference, so much so that even though I explained Valentine’s Day to him, after much questioning from him about it (and my manager) we both still got a Valentines eCard!!!! Read into that what you will. He did say he was happily married with kids! I did see the photo on his online CV – yes well...
Project 2 and Developer 2 (MCAD + too) was quite different. Again pleasant and courteous but not a team player. Would rather read the documentation and the code on his own. Asking the occasional question. Well on the face of it a very able person.
So by the end of the month they both went back to their place or origin. I thought we that’s the end of that they seem to have enough information, documents and source code to get on with it. Two weeks later, there was a deluge of phone calls all requesting a teleconference with me and my manager to try and understand the projects. Project 2 more that Project 1 I have to say but nevertheless. Conference calls took hours and were frustrating due to the time delays, time difference and waiting for a large number of people from their teams to join the calls. Unbelievable.
Bear in mind that I had done about 70% (at least) of the major work. Classes in place and a few design patters ( documented in the code and hardcopy). I would say a by about 3-4 month – 6 at most it should be job done (on both) a small team of two may three. 18 months later I called my manager to get a reference and enquired about the projects, only to find both were still being developed! I was surprised by manager was beside himself! He was totally against it from the start. Bottom line, on paper, it looks like it can save money. In reality, it costs significantly more.
Case B is my experience as well.
I did notice that the project that succeeded used the more agile approach--the offshore developer wasn't co-located, but he was integrated effectively. It isn't really about nationality, especially as the Asian parts of the world are more focused on education than the U.S. seems to be. It is about expectations and rewards. If you invest in a developer, he will invest himself in his work. If you make it clear he is just a generic hired-hand, don't be surprised if you get McDonald's code instead of Cordon Bleu.
Bottom line, off-shoring didn’t work full-stop. Someone somewhere was making money at the expense of the projects.
@John would suggest this an issue of "all the good devs have come onshore". But I think that worker migration is really a side-effect of efficiency. Just like there are developers worth $100 / hour, there are developers worth $5 / hour.
Your Company "A" example was successful because it assumed that people had some value priced in and it put the burden of pricing on you directly (instead of indirectly via some firm).
Right there I stopped reading and need to ask: "WHY??" Do you not live in a nation where you could at least keep the employment INSIDE the nation?
This is part of the cancer called outsourcing - it destroys nations from the inside-out.
The secret ingredient for successful outsourcing is IMO to only outsource work which can be reasonably outsourced. Besides finding the right provider, this means you should only outsource work packages which have a low surface to volume ratio, and for which requirements can be defined unequivocally without much effort. And you have to stick to your part of the bargain: define the interface and don't change it continuously.
You can't expect a remote team to be as productive and effective, and understand everything the same way your on-site programmers do. For one, they don't have access to the same information stream - most of which your on-site people absorb without being aware of it. Getting remote developers on-site for an introductory period works, but is IMO not very efficient - the process needs to be repeated frequently, and your costs increase more than if you'd hire local programmers.
For your in-house programmers, you rely on knowledge transfer which happens in tiny bits, through lots of half-a-minute discussions during many days, via internal-only emails, by observation of business processes which are not visible from outside etc. This simply can't happen with remote developers. They have to have good requirements and build up a body of knowledge of their own. If you can't provide this, forget outsourcing.
A good outsourcing company has the expertise and processes in place to identify work fit for outsourcing and to manage the knowledge transfer. If you really want outsourcing to get you somewhere, listen to them, and don't try to enforce your processes - your in-house processes are most likely not fit for outsourced work.
All in all, successful outsourcing requires a cultural adaptation on the side of the buyer, something of which many companies are unaware, and something which most companies are not willing to do.
In the replies from other people, I recognize a few more important aspects:
1. Think about WHAT work you outsource (and a project that is already underway is not the easiest to start with as in project B)
2. Invest time in transferring the (domain) knowledge to the offshore team
3. Invest time in team building
I think the key is that offshoring does work, provided you do the right things. Software development is complex in itself, doing it offshore brings some extra challenges. But just as software gets built, if you do the right things, offshoring will absolutely work. And it brings you many benefits (a.o. talented people, lower salaries, faster scaling, flexibility). There are some interesting articles on this topic on our blog: http://www.bridge-outsourcing.com
So the base thing is communication and taking the right person. If your company has a good developer he can always use the right tool ( eg git , svn etc ) to track and evaluate the codes he commits. Don't want to monitor with a screenshot software or any or just look only in the last moment to know the work done for the past months was a crap.