Cliff Rowley wrote:
I shouldn't worry too much, almost every report I've read and every
experience I've had featuring Indian development houses has turned out
bad. The fad won't last too long. At least only as long as people
realise they aren't really saving money having to rebuild bad work.
This is somewhat deceptive -- the failures get a lot more attention than the successes.
I've managed projects like this and worked with people who've managed projects like this. Some have succeeded and some have failed -- a lot depends on how engaged you are in management.
If you take the hands off "we'll hand it a loosely worded spec and an imaginary schedule" approach that most companies use for in-house development you'll get the same inevitable implosion. Multiplied by the fact that they can't walk down the hall and say "uh, what the #@%$ do you mean here?", the fact that you're approximately on the other side of the world and thus the most trivial of communications takes 36 hours to bounce back and forth, and so on and so forth.
You also have the matter of cultural differences. It is a mistake to think this means "Indian" vs. "American" -- this just means separate offices only with fewer occasions to interact (and sometimes where one of the offices resents the other). Take your average Silicon Valley office / East Coast office cultural divide and add the aforementioned 36 hour round trip times and conference calls at unpleasant hours with a satellite delay of several hundred milliseconds, and you've got yourself a party. People stumble on this, thinking "hey, we have Indian engineers, problem solved!" It's an easy stereotype trap and doomed to failure: you have two different offices with two different sets of people who spend all their time around their own office, and hemisphere of birth has approximately nothing to do with it. If you're not talking all the time you're setting yourself up for failure.
On the other hand, if you address all of that head on you can succeed. This means extensive communication, adequate compartmentalization of responsibility, active tracking of who's doing what, by when, and exactly what "what" is. This sometimes means a requirements analysis team whose job is to make sure the spec thrown to India is bulletproof, and a management team on both sides of the world looking for hurdles and smoothing through them.
By now you may be noticing I've mentioned a bunch of people there who aren't coding. This means more overhead, which means the project is big enough that the cost of having those people is smaller than the savings for the number of developers overseas. This means that it isn't three engineers in the basement, or even most mid-sized XP teams.
OTOH, the demand for Indian development is tapering off because the invisible hand has driven the costs up. Next up... Shinzen? People are having some good luck with offshoring to South America, where at least you can come in in the morning and have a phone call before people leave for the day.
YMMV
-faisal