I'm a partner at a Ruby outsourcing company in Argentina. I sympathize with the author, but I think the conclusion that outsourcing doesn't work is overly broad.
The crux of the problem is that working with a remote team is a very different proposition than working with people onsite - a fact that is obvious but that people generally fail to act on.
Quite often at my company we're contacted by clients want to hire folks in a foreign country and expect them to work like remote employees, but cheaper, and with fewer legal responsibilities. They think that through the wonders of Skype and email, people in India (or South America) can work just like on-site employees.
The reality is that outsourced development to remote teams only works when the client is willing to adapt their own work patterns to it. As a client, you need to:
* Have a crystal clear idea of what you want built. The less communication overhead you have with the remote team, the easier your life will be, and the more likely it will be that stuff gets implemented the way you want to.
* Have frequent and early deliverable dates. Don't start a project that will take 6 months to get a first release out with a remote team. Shoot for as early a release as possible, followed by frequent small releases. This lets you pull out almost whenever you want and also reduces the likelihood of burning out the developers on the other side.
* If you already have a company with a bunch of people, have the remote developers work outside your regular dev cycle. Don't expect to plug in a couple of guys located 5 times zones away into your regular team, unless your regular team is already distributed.
* Be linguistically very compatible with the folks you're outsourcing to. If you have any difficulties understanding or being understood by the folks you're hiring, then you're significantly increasing your risk.
The well known Ruby consultancies like Pivotal, Thoughtbot and Hashrocket will all tell you, that outsourcing to foreign countries is a mistake, and that developers need to be on-site. This, of course, while basing a huge amount of their business on Rails and a bunch of other open source libraries and frameworks which are developed almost entirely by distributed teams. These companies have an economic incentive to lead people away from outsourcing to cheaper countries, so follow the money.
It just also happens to be the case that since many clients don't understand how much their own workflow needs to change, many outsourced projects fail and reinforce the idea that outsourcing doesn't work.
> Have a crystal clear idea of what you want built.
> Have frequent and early deliverable dates.
Both of these things are extremely difficult (if not impossible) for experienced software consultancies to know up front, let alone the crowd looking to outsource. More importantly both figuring out what to build and knowing when those things are deliverable have, in my experience, required the involvement and input of the developer.
A lot of companies are looking to build simple, mainstream projects. For example "add a shopping cart to my site." Those are easy projects for outsourcing. If the client is looking to do something that has never been done before, then outsourcing may not be the best idea.
I think that's his point. Outsourcing doesn't eliminate your responsibility as a customer to participate in the development process -- it just shifts part of the labor to another entity.
Telling an outsourcer "do X for me", where X isn't a well defined thing (ie. run a warehouse, manage windows servers, etc) is going to be a disaster. What does "add a shopping cart of my site" mean? Do you want to figure out sales tax for various jurisdictions? Do you need to to interface with the German banking system? Is there a configurator?
If you treat an outsourcer as a partner in development and participate in that process, you're either going to get a result that makes sense, or you'll figure out that the process isn't working out and terminate early.
Except rarely do projects like "add a shopping cart to my site" turn out to be that simple. Each project has unique circumstances, and applying a one-size-fits-all attitude to the problem is never the right solution.
This is why I am not too concerned about outsourcing [1]. Most of my projects start with a 'this would be neat' sentence and then it's left for me run with. I know the business and the people so that's usually enough for my team to get a first iteration completed. From there we add users, get feedback and iterate again.
If businesses have a crystal clear idea of what they want then chances are there is already COTS to satisfy that need.
[1] Jobs are never promised and a PHB at anytime could decide that the company doesn't need tech, but that's not really an outsource problem.
For a project of any significant size :
* Have a crystal clear idea of what you want built.*
This is itself most of the work. It is surprisingly hard for business people to understand that writing software is actually "specifying What needs to be coded" for 50% of the effort.
Right on. I don't mean companies need to have a project spec in hand from day one though, but rather that their own goals are clearly defined.
I'm happy to help them come up with the spec. But if the client can't give you an elevator pitch for what you're going to build for them, run for the door.
"Have a crystal clear idea of what you want built."
Rarely have I ever worked for a company that knows this. The last company where I worked would change their mind mid-stream every couple of weeks and it added almost a year of extra time onto the final release date.
It's usually not this bad, but if more companies followed this (not even just with outsourcing), there wouldn't be as many failed projects.
It isn't bad to change requirements depending on user feedback. You can have the best implementation in the world, done after the best specifications in the world; but it's all for nothing if customers don't want it.
This is where you need to take small deliverables from what they say so that they actually get something usable at each step. It's almost impossible to have a consistent and useful goal that's years away. Expecting otherwise will just lead to disappointment.
The crux of the problem is that working with a remote team is a very different proposition than working with people onsite - a fact that is obvious but that people generally fail to act on.
Quite often at my company we're contacted by clients want to hire folks in a foreign country and expect them to work like remote employees, but cheaper, and with fewer legal responsibilities. They think that through the wonders of Skype and email, people in India (or South America) can work just like on-site employees.
The reality is that outsourced development to remote teams only works when the client is willing to adapt their own work patterns to it. As a client, you need to:
* Have a crystal clear idea of what you want built. The less communication overhead you have with the remote team, the easier your life will be, and the more likely it will be that stuff gets implemented the way you want to.
* Have frequent and early deliverable dates. Don't start a project that will take 6 months to get a first release out with a remote team. Shoot for as early a release as possible, followed by frequent small releases. This lets you pull out almost whenever you want and also reduces the likelihood of burning out the developers on the other side.
* If you already have a company with a bunch of people, have the remote developers work outside your regular dev cycle. Don't expect to plug in a couple of guys located 5 times zones away into your regular team, unless your regular team is already distributed.
* Be linguistically very compatible with the folks you're outsourcing to. If you have any difficulties understanding or being understood by the folks you're hiring, then you're significantly increasing your risk.
The well known Ruby consultancies like Pivotal, Thoughtbot and Hashrocket will all tell you, that outsourcing to foreign countries is a mistake, and that developers need to be on-site. This, of course, while basing a huge amount of their business on Rails and a bunch of other open source libraries and frameworks which are developed almost entirely by distributed teams. These companies have an economic incentive to lead people away from outsourcing to cheaper countries, so follow the money.
It just also happens to be the case that since many clients don't understand how much their own workflow needs to change, many outsourced projects fail and reinforce the idea that outsourcing doesn't work.