I used to feel the same way, but I've come around a little bit over the years. I've worked on projects where a portion of the work was augmented by an offshore

I used to feel the same way, but I've come around a little bit over the years. I've worked on projects where a portion of the work was augmented by an offshore participant. It works when the specifications can be produced easily and written without onerous oversight. It also helps when it's work nobody on the team wants to do. Your sentiments about it are important, though, which plays into that last sentence. When a dev team is presented with "we're offshoring this and you're going to help" they tend to have a bad attitude about it and subtly (possibly unconsciously) work against the project's success. When used properly, the team enjoys the lighter workload and doesn't have to work on "non-sexy" things. In our case, we had a very complex, old protocol that we needed a C# library written for. No commercial implementation was suitable, and it wouldn't have been technically difficult to write, but it would have taken a long time to do, so we pointed the small offshore team at an RFC and our expected interface and wrote the rest against that interface. A few weeks before the first prototype, we wired it up with their code. It worked brilliantly and I don't think anyone on the dev team even talked to one of the offshore developers. It's important to mention that in this case, the offshore team cost about 1/3 as much as it would have cost to bring someone on to do this work (deadlines couldn't be extended) and there wasn't any more work that we could have put that person on afterward, so it would have been a short-term hire. There are parts of many software projects that fit here -- it falls apart when companies think all of software development fits. There's a difference between tightening 900 screws to the right torque with a precise manual vs. designing and building the entire car.