OdeToCode IC Logo

A Tale Of Two Offshorings

Thursday, February 16, 2012

Company A

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

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.

What I Take Away From The Experience

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.Iron Triangle

Gravatar Diego Mijelshon Thursday, February 16, 2012
IOW, offshore has nothing to do with quality, and good project management has everything to do with quality :-)
Gravatar Chris Sutton Thursday, February 16, 2012
I've seen that mythical beast more than once. :)
Gravatar lynn eriksen Friday, February 17, 2012
Gravatar sean Friday, February 17, 2012
I have been involved in and witnessed countless offshore projects and without doubt it is false economy. Sure you may save money (which is arguable if you add up actual man hours etc etc in actually project managing something like this) but it fails to take into account the frustration, the communication and frankly the b$"£$^ problem that comes with it.
Remember for every business case i favour of outshoring I could produce a business case that completely contradicts that including the financials
fuzzbox Friday, February 17, 2012
Undoubtedly there is talent out there but I haven’t seen it in my dealings, I mean this with no disrespect. I worked for a major telecoms company in the UK about 6 years ago. I had two high-profile projects I was working on. The powers that be decided to offshore both of my projects (within a three interval) to save money and to save time by bringing the projects in early. Both projects we small to medium size. My manager supplied the know-how and (most of the stored procedures) and I supplied the coding expertise. Since he was in the design from the start some 10-12 years previous. He knew the system inside and out and was the first line support. He was that good he could sort most problems with in 30 mins or so. Both projects were similar but not the same and no real commonality (or code reuse). The original app was written with a mainframe, then translated to VB5/6 and with me VB.NET. The project were complex and needed understanding. The documentation was limited with a lot in my bosses’ head. Anyway I digress.

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.

Tom Z Friday, February 17, 2012
The quality of coding/development really depends on the quality of an individual developer, not so much to do with offshoring or not.
Pablo A Friday, February 17, 2012
Definitely had much of the same horror story experiences with offshore development... I'm sure there are some good, but I've yet to run into that.
Gravatar tobi Friday, February 17, 2012
To the point. Like.

Case B is my experience as well.
Gravatar john Friday, February 17, 2012
All the good offshore devs have come onshore - you get what you pay for - as ever.
Gravatar Lisa Morgan Friday, February 17, 2012
There are good developers everywhere. There are bad developers everywhere. But no matter what, the Iron Triangle rules. If you want good code cheap, it takes time. If you want good code fast, it takes money, and if you want cheap code fast, you'll wind up doing it over anyway!
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.
fuzzbox Friday, February 17, 2012
Lisa - huh! its nothing to do with education. Nationality does have a bearing, language or a cultural difference. The experience that I had was the senior developers, managers didn’t communicate the whole picture to the team only a small part. Knowledge is power. I saw this first hand. Mistakes were made due to the wrong assumptions being made. It was a costly disaster that had a lot of repercussions for a long time after. As I mentioned above they had the education (MCADs, etc and speak English) but very little in the way of experience. The best was sent over to take over my projects. Well, if that is the calibre… But I have no wish to be rude so I’ll stop there.
Bottom line, off-shoring didn’t work full-stop. Someone somewhere was making money at the expense of the projects.
Gravatar Gates VP Friday, February 17, 2012
The problem with off-shoring of type B is that it assumes that the market overseas is inefficiently-priced. Employers are hoping to get equivalent labor at lower prices under the assumption that such a thing exists.

@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).
Gravatar Mike Sunday, February 19, 2012
"they recently decided to start working with an offshore consulting company"

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.
Gravatar Scott Sunday, February 19, 2012
@Mike - they tried for 5 months to hire engineers - it didn't work. We need fewer finance and psychology majors and more engineers.
Gravatar Eric Tuesday, February 21, 2012
I have found a consistent problem when a company looks for months, can't find adequate developers, then decides to outsource. Inevitably, they do not spend the same amount of time interviewing the developers from the outsourcing company as they did when they were looking locally. They just hope that the company will hire good people to work on their project. The problem is not the outsourcing to another country. The problem is with outsourcing your responsibility for finding qualified people to someone else. And that seldom works.
Anonymous Coward Thursday, February 23, 2012
I worked in an offshoring company pretending to provide good services for good money for about ten years. IMO, we did what we said we do, so I thought I'd share a few thoughts.

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.
Gravatar Hugo Messer Thursday, February 23, 2012
I think in project A, you described some of the crucial ingredients which are needed to make offshoring succesful: A. Hire the right people; B. Use a clearly defined process.

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
Gravatar Hari K T Friday, February 24, 2012
I agree with Hugo, Knowledge about what you are going to build is the first one you need. If a project fails, its due to the communication failure mostly. The projects future plan may not be transferred. It may be in mind of the client, but not in developer. The basement of the project plays a huge role in maintaining and scaling an app.
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.
Comments are closed.