A few years ago I was in Bali for a fitness bootcamp. Whilst watching TV late one night, I came across a documentary on the construction of an underground railway system in Amsterdam. I vividly recall one of the engineers being interviewed saying “it’s impossible, but we’re going to do it anyway”. When I think of some aspects of outsourcing, I remember this statement because there definitely are some tough challenges in getting outsourcing to work, but I believe it can be done.
I should begin by saying that by no means am I an authority on working with outsourced programmers, in fact, I’ve only done it for a few months total. My brief experience with outsourcing revealed both good and bad aspects of the approach, but more importantly, it opened my mind to the possibilities. I have noticed that some people seem to be against outsourcing for personal reasons, and that is surely their prerogative.
In some ways this article is a retort to a piece on outsourcing I recently read. The article in question is by Michael Bean and is titled The Pitfalls of Outsourcing Programmers. It is one of the selected works gathered together in the book The Best Software Writing I – Selected & Introduced by Joel Spolsky.
Am I attacking what the author had to say in the article? No way, it’s very well written and full of insightful information. Some knowledge of what the article is about is required in order to understand my perspective on the matter. I don’t want to re-write the article, so I will just cover the main points very quickly.
Michael Bean discusses the following ideas:
There has been a rush in recent years for US companies to send development tasks to India, China, and Eastern Europe.
Software development is design not manufacturing. Therefore, by virtue of its creative nature, it’s not something which should be sent off-shore.
People pay for ‘value added’ services or products. If all aspects of a company’s offering (from production to customer service) are outsourced, they cannot give customers what they truly desire.
Outsourcing customer service is equivalent to saying you aren’t interested in hearing what you’re clientele have to say.
The motivation behind setting up a massive IT work force overseas goes like this; “if Nike can do it with shoes, we can do it with code”.
The “but you are taking away jobs from Americans” argument is spurious at best, people in India or where-ever have just as much right to work as anyone else. We are living in a global economy after all.
When a business outsources innovation related task, they give away their competitive advantage. Over time, a company will lose their capacity to innovate.
Innovation suffers when people are spread across different countries since they can’t communicate effectively.
Outsourced programmers aren’t around for the long term. They tend to disappear after the project is over, taking with them any specialist knowledge they have acquired.
Completely outsourcing all of your development is a bad idea (i.e. both design and coding of the software).
The difference between United States and Indian time zones means there is no overlap between their working hours. This makes communication even more difficult.
Creating software is more about design then assembly. The ability to design is also considered an uncommon skill.
This is basically the crux of Michael Bean’s article. I’ve done my best to retain his core ideas, but obviously there is the risk of misinterpretation.
I have to agree that it is undesirable to outsource everything (i.e. both design and coding). In Michael Bean’s article, he doesn’t really go into what he means by design. To me, design means the functional specification (i.e. how the software will work from the user’s point of view).
Would I trust an outsourcer to write a functional specification? No. This is not meant as an attack on the skill of overseas programmers, it’s just unreasonable to think you could get a remotely accurate spec without meeting a client face-to-face. Would I trust outsourced programmers to create software based on one of my specs? Yes, definitely.
The other problematic aspect of Michael Bean’s article is that it doesn’t explicitly mention a division between shrink-wrapped software development and custom software projects. This is a major consideration. If you are trying to minimize production costs, then outsourced programmers are very well suited to custom development (and yes, maintenance is a big issue, but it’s a big issue with normal companies anyway). Reducing operational costs may be a very real concern if your business has investors or venture capital.
There are strategies for having outsourced programmers work on shrink-wrapped software, for instance; some Indian companies offer dedicated teams that only work on your software, they even come complete with their own dedicated project manager.
It’s true, you’re communication will take a hit, that is unavoidable. But you don’t get something for nothing. If you want to produce software for 50% of the normal cost, then be prepared to put up with some discomfort.
Luckily, in Australia we don’t suffer from the same time zone issues our American friends have to endure. In my experience with Indian programmers, I found they began to stir at about 12 noon, that’s just fine as far as I’m concerned.
Communication and project management tools are very important for successfully working with outsourced programmers. MSN or other instant messaging software is the key. I remember having three different IM software running on my computer at one point in order to keep in touch with everyone on my projects. A project management tool like Basecamp is also very helpful. A bug tracking system is another great idea, and an online schedule that can be viewed by everyone will make life a lot easier.
Perhaps this is a little simplistic, but it seems to boil down to this: outsourcing results in cheaper software development, but in-house teams produce better quality software.