A little background:
I work in the information technology industry, so I see first hand what this outsourcing stuff is all about. What exactly is my job in IT? I'm the technical lead on various internal company projects, one of which is a pretty significant decision support systems project. This particular project is like a huge ongoing, entity and is always changing as new business requirements come up, so it will never be "finished" in the sense that most IT projects have a target finish date. The overall project actually consists of many smaller projects that are meant to cover a wide variety of business requirements. The overall project would get killed if some executive decides to cut our funding. That scenario becomes less likely as we get more people in the company using our system, so it's in our best interest to get as many people as we can working with us.
Here's my experience with offshoring on this project.
I do coding and software engineering work as part of my job, but if the sub-project is large enough, I'll delegate some of the coding to other developers assigned to my project, who are mostly stationed outside of the United States. I'll be responsible for the overall solution, making sure that the pieces I design work together for the solution being created. We use these guys in this case for the same reason that developers get offshored there: the labor is cheaper. While a specific American's job isn't being lost to a foreign worker for this specific task, this usage of foreign labor is still part of the push to move development jobs to a cheaper labor market. Basically, it's one less American wage that needs to be paid for the project.
Before you ask why I haven't been offshored myself (yet?!? uh oh), it's worth asking exactly what kind of work is being sent overseas in this case. The work I delegate to others is pretty simple development work, like coding a simple web application that interacts with a database, based on a predefined design and predefined logic. Quite frankly, if this is the kind of work I did all day, I'd go insane of boredom. This kind of development is mind-numbingly trivial and I'd rather have someone else do it anyway. Defining the design and the process logic to solve an actual problem (what I do) is what I find interesting, so I prefer to do that. That is also the kind of work that is least likely to get offshored, since it requires good communication skills and solid understanding of business needs, along with having enough technical skill to translate those business needs into a real technical solution. Knowing what questions to ask is part of this. These aren't skills you learn from a programming book, or in a technical trade school (that I'm aware of).
You may have heard that offshored labor produces equal or better products than what's produced in the U.S. In my experience, that's an illusion. You can have lousy programmers in India the same way you can have lousy programmers in the U.S. I've often gotten back code that *almost* worked. It may have run without errors, but that doesn't mean it is totally correct, especially if it wasn't tested thoroughly. Now, when I say "test", I don't mean using a sophisticated, organized testing process that involves prewritten test cases run by professional software testers. I'm referring to simple functional tests. Write some code, run it, and see if it works the way you wanted.
Here's an example of the "quality" I'm referring to. Part of a project involved writing a simple web application that stores data in a database and allows the user to edit it. It's the kind of application an experienced Perl web programmer can finish in a day, if not a few hours. I was also very specific when I gave him the specs for the program. When I tested the completed work, I found that entering a single quote into the fields crashed the application with it tried to store the data. When I looked at the code (which is not something I should have to do, but whatever), I found that he was not following some common best practices for interactiing with a database. Aside from failing completely, the way this was written made our database server completely open to what is called an SQL injection attack, which is a kind of exploit that can enable an attacker to run arbitrary commands on a database server via the web. Not good.
So I send an email to the developer informing him of the problem, along with a suggested solution. So he fixes it... Almost. He informs me that single quotes will be automatically converted to double quotes so it doesn't crash. I'll have to tell my customers this so they know why the text like can't appears as cant"t. Or how about 6' becomes 6"?
WHAT??!?!??!?
I've written tons of applications like this. It's possible to throw any garbage you want at the system without it crashing (barring bugs in the middleware), if you write the program correctly, which is not hard to do. So I finally get him to fix this correctly. How much was really saved with the lower wage after the wasted time? By the way, this correspondence took several days, since there was at least a 10+ hour turnaround for each email sent because of the time zone difference. Could I have done the fix myself? Technically, yes. But I was working on other, more thought-intensive things in a time sensitive environment at the moment. That was the point of delegating this work in the first place. If best practices were followed, this would not have been an issue. I can only conclude negligence on the part of the developer, since he usually produces decent code. Proper handling of user input is essentially an implied requirement for any programming project. I was shocked to see such results on a programming task this simple.
In addition, the same developer, on the same project, told me that a certain feature of the application could only work in IE when I mentioned that it did not work in Mozilla during testing. Company standards dictate that all web pages we develop should work correctly in both browsers. This was one problem I just fixed myself. It was a one-line code change.
This kind of thing wasn't an isolated incident either. We had a similar situation with a different developer on a different project not doing basic error checking. This was written such that if the initial step in the program failed, where a successful condition was required to continue, rather than simply aborting with an error message, it continued processing anyway! I find this kind of thing unacceptable. Error checking like this is an implied requirement. Again, this was done by a developer who was not new to the technology or software design in general.
I have other examples of this, but I think you get the point. Whether it's incompetence or negligence, I don't buy the quality argument at all.
I didn't see language barriers as an issue in dealing with these folks, especially since all correspondence was done via email. We understood each other well, or so it seemed. What got me nervous though, was when questions were not asked. I send a list of specifications, but often got no requests for confirmation of details, which usually follows a requirements review. I would even send mockups of what the application should look like, so that they have a visual aid in case the written specification is not totally clear. Part of the problem, I think, is when a developer doesn't know how their assigned piece fits into the bigger solution, quality can suffer because they develop in a vacuum and do not see things that the higher level designers see. This could be one reason why questions are not asked after reviewing requirements. This is why when submitting specifications, I try to include a diagram of the whole solution with their assigned piece pointed out in it. This helped on the last project I did with foreign labor. Of course, It's good to do this when the labor is local too.
You can kind of tell whose job is going to get offshored. If all you do is write code according to some predefined specification, you are easily offshored. It doesn't matter if you're the best coder around. Management doesn't usually see the code. It only matters if it works well enough to not cause any complaints. Those technical folk around me who are actively doing something that involves leadership of some sort have managed to stick around.