Why I Will Never Feel Threatened by Programmers in India

This. Over the years I've been involved in cleaning up horrible messes created by US based consulting companies using US labor. The incentive is to sell you hours, not to sell you a working product, and the outcome is predictable.

I have not doubt you can outsource your programming work to India if you do it the way companies like Oracle and Google do it - go to India, hire your own management, hire employees, and give the local managers enough authority to manage the project in their time zone.

People are missing the underlying root cause of the lower quality programmers in India -- Culture. There, upward mobility is the goal, not being the best programmer. People take a programming job for a year or two, then look to "advance" into management/leadership/etc. So the result is a large number of junior programmers.

That, in turn, is why you need to give very explicit instruction, and why much of the work needs a lot of QA.

Knowing this also makes it a lot easier to interview firms or individuals, looking to their own personal motivations to see whether they match the overall cultural trends or not, and thereby you can build a better team.

I've worked with outsourcing both to India and Eastern Europe in three passed companies. Your comment of ratios of "good programmers" to not, particularly in India is spot on.

A lot of outsourcing to India started with Enterprise Java applications, MVC/CRUD type stuff that was simple, but also time consuming. So, it made sense to move the tasks that didn't take advantage of your strong programmers overseas to help with the burden. A number of outsourcing firms WiPro, Global Logic, etc. started with this model. Many, even well into the mid/late 2000s worked on these same Apps. It was their domain of "expertise". Teams were generally set up to have a "good programmer" as a lead/architect that was often your main contact and was responsible for one or more junior developers doing the work. Even if you had a strong set of requirements and a good relationship with the lead, implementation could suffer from the "chinese whisper" effect -- what you request gets distorted the further down the chain it goes. For CRUD apps that weren't performance dependent, this was fine.

As the push for outsourcing continued, from my experience, these formerly Java Enterprise app shops were asked to do more diverse projects. The majority of the ones I had to work with were a failure -- if they kept the same team structure -- i.e., remote lead who oversaw remote juniors. The biggest cause wasn't necessarily one of background, it was more turnover and drive. The churn was very high and developers were asked to do something boring or beyond their skill set (or, the still lingering issue of sticking to actual requirements).

One prior startup I was at outsourced non-core monitoring stuff that was a reasonable success. However, a local executive was all hung ho about outsourcing more core technology until a couple of us put our foot down and indicated the unaccounted overhead of the local work needed to fix things. That stopped that angle. At the same time, we had amazing success outsourcing targeted pieces -- an arm assembler optimization of a key piece of crypto code, being one.

The reason for the success? The coupling of a bounded small project that was sent to a team with that relevant skill set. This is the key area where outsourcing is successful. Bounded projects, targeted to a team with the relevant skill set, and good communications between them.

Where outsourcing fails is the generic skill set approach nd overhead that most of the big firms employ. Local management just sees the reduced dollar and doesn't account for the extra time -- to fix, to integrate, and to iterate on deficient deliverables.

This isn't an india / US issue. This is a good approach regardless of the topic. It just happens that India was the envouge outsourcing destination and the majority of US Management solely focused on the assumed reduced cost.

You are making a good point. I'm from a third-world country, and I'll tell you why: they shouldn't be developers in the first place.

1. Communication: They fail to communicate not because English is not their native language. They'll also fail in their native language. Communication is a skill. English is a language. They don't invest to learn good communication, and also to learn the language.

2. Coding: They are bad coders. They don't produce good code because they don't want to learn version control, unit testing, and programming patterns. They are too lazy to open up a book and read. They are too lazy to subscribe to programming blogs and listen to podcast. They think that what they learnt in school and university is more than enough.

3. Creativity: Briefly, they can't look beyond their room window. They don't bother to know if the UX is good enough or the kind of audience for their product. They don't want to create. They prefer to copy/paste.

This is not India. This is most of the "developing" world, a also a part of the "developed" world.

At the big company where I work they're actively getting rid of their US-based employees and hiring in India and China. My employer isn't one of the ones I mentioned above. But I know from friends working there, that this is the case there as well.

I think there are a number of reasons for this.

1. Many engineers just aren't interested in the old fogey US tech companies. Do you think a smart kid out of a US college would be more interested in working at Google/Facebook or at Cisco/Microsoft? As a result they have a tough time hiring. In India, people actually LIKE working for the man at big giant companies. It is a status symbol. So its a lot easier to pick up good talent there even if the company is regarded as a has-been in Silicon Valley.

2. At some point in a tech company's lifespan, decisions seem to be made purely for financial/cost-saving reasons instead of for product/customer reasons. This is usually the point at which good engineers start leaving the company because they realize the bean counters are running things. This is also when these companies start expanding their India ops. Word gets around, and hence this is somewhat co-related to point #1.

3. Empire building: For some weird reason, engineering managers love having a lot of reports. Its reasonably cheap and easy to staff up in India and China, which means an engineering manager at some loser company in the US can get to brag that he (its always a he) has 100 engineers reporting to him.