[mbesto]

First, I was working as a consultant to work with organizations who off-shored there sys admin work. As a consultant I found myself having to document something step by step to the India counterparts. Why on earth does this make any sense to hire such people when I could simply do it myself? I've looked at the costs and they could hire one good on-site consultant for the price of 3 bad Indian ones. This is the age old consulting/outsourcing paradigm of "let's just throw more bodies at the problem"

Second, the expensive Indian outsourcing firms are not advantageous to do business with. (1) What's to stop the employee turnover when these people are sent to the US under H-1B visas? Large corporations (in the US for example) often exploit this ability. (2) What then becomes the cost advantage as opposed to near-shoring it?

I think that's why countries such as a Romania, Hungary, Bulgaria, Ukraine, Czech Republic, Argentina, and Brazil are up next as the areas to blossom for outsourcing. These areas foster strong technical skills (and strong educational systems to back them) and are still at a fraction of the price of their "1st world" counterparts.

I can't claim to be an expert on outsourcing economics but I see and breathe the issues and benefits of it everyday.

[statictype]

Well, I think we're looking at it from different angles.

You see good outsourcing companies as those that have technically competent engineers. That's not how I see it.

I think part of the reason big companies are still outsourcing to India is not because of the low cost of technical competence, but rather, the low cost of process management in developing IT-related software.

For example, when you outsource a module to be built by the offshore team, you may end up with code which is not world-class quality in terms of maintainability or performance, but you will end up with something that matches the requirements you gave. And if something seems out of place, they will be able to trace it from the bullet point in the requirements.doc file down to the module stored in VSS (yes, sadly, probably VSS, not subversion or git), to the unit test cases that cover it in unit-tests.xls.

This is because all the companies that are outsourcing their IT are not doing it in the hopes of getting good code, or because they're not technically competent enough to write the required code (most outsourced code is of the CRUD variety as people have mentioned here) they are doing it because its cheaper than having a whole team to track requirements, and make sure they map to UI elements in the right places and that the code is documented in a way that someone down the line won't be able to complain about it not being understandable, and that the unit tests are in place and all of them are checked-off.

I guess if you're outsourcing work that requires technical competence, maybe you're right about other countries working out better (I have my doubts but don't have any reason to disbelieve you) but I think a majority of the outsourcing success stories (involving India) work because their outsourcing needs have less to do with the actual code quality and more to do with the process involved in writing boring enterprise CRUD apps.

[mbesto]

Absolutely agreed -> low cost of process management in developing IT-related software.

The issue I have with this is that success (if you could call it that?) in enterprise IT is driven by both competence in both process management and engineering talent. The paradigm (and the fallacy) of today's IT is that the enterprise sees IT as largely commoditized. What would happen if, for example, a CRUD application was built by developers who understood the benefits of UI/usability and this increase performance/productivity of a salesforce? Naturally I'm inclined to think the 'Enterprise' would simply write off IT's existence ("let's cut costs and send it to India!") and praise the salesforce ("another great quarter of double digit growth")

I think it's wishful thinking, but whatever happened to using to technology to solving strategic problems?

[hga]

I have an even more reductionist angle: if you look at the success rates of these sorts of IT projects, total failures are somewhat less than 50% but general failures, the latter plus systems that lack significant functions that were part of the requirements are well over 50%.

So you might say that doing this sort of IT is akin to cargo cults: these organizations aren't really doing it, they're just pretending to themselves that they are.

So, if you're going to fail, why not fail as cheaply as possible?