Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 11/03/2008 07:13 AM, Grant M. wrote: > I have to agree with the other posters, or at least in general. The > things that are the most problematic with offshoring is language > barriers and expertise. The former can be overcome with a bright, > bilingual project manager, however the latter is why you get "software > developers at McDonald's wages". It's because your paying McDonald's > wages, not because they don't want to make more. Back in the mid 80's, > you could buy a brand-new, dealer-fresh car for only $3990. That car wa= s > the Yugo. > > I have however worked with folks from overseas that were reasonably > skilled, listened well, and had a decent grasp of English. However in > every single one of those cases, those folks tended to leave their home= > countries and come to the U.S. (or were already here). The offshore > talent that deserved better than being offshore talent eventually becam= e > on-shore talent, which is generally what I would expect (assuming that > is what they wanted to do). If you're good, someone will offer you a > position, wherever that might be. > =20 Back when I was at Digital,we had a division in Bangalore. One of the=20 engineers came over here to train, but left shortly after he returned=20 because he was able to find a job over here. However we did have quite a = few other people there. Digital moved the Unix Tools group to India, and = one thing they found out is that whenever you manage people, you need to = understand their culture. One problem was that when someone would file a = problem report, the engineer would treat the problem report as gospel,=20 and apply the fix. But, in many cases, the solution may have fixed the=20 perceived bug, but broken the tool (or violated standards), or that the=20 perceived bug was not really a bug. Remember, especially in the=20 commercial Unix environment, most tools must behave according to the=20 relevant standards, and in our case both Unux9x as well as SVID and=20 POSIX. One thing they ended up doing was to have someone prescreen the=20 problem reports. My personal dealings with the engineers in Bangalore=20 was pretty good, and at the time I thought it was a step up from the=20 people we had in New Jersey. As I alluded, the issue is not only=20 language but also culture. This would be true anywhere, not just India. --=20 Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |