Cliff R. 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
