File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Jobs Discussion and the fly likes Cringley offshoring article Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Careers » Jobs Discussion
Bookmark "Cringley offshoring article" Watch "Cringley offshoring article" New topic
Author

Cringley offshoring article

Richard Scothern
Ranch Hand

Joined: May 25, 2001
Posts: 83
This has some points which I think are rarely discussed.
http://www.pbs.org/cringely/pulpit/pulpit20030814.html
Richard
Greg Neef
Ranch Hand

Joined: Jun 16, 2003
Posts: 82
I can certainly support two points in this article.
One, large consulting organization's incredible inefficiency and short sightedness. I worked on several internal projects at one that actually had more 'managers' than programmers and analysts and don't even let me get started on their training. I'll leave it at the fact that they canceled all training opportunities about 2 years ago and then laid my a** off when my skill set was not consistent with the current needs.
Two, I have been in discussion recently with one consulting company out of India for two different engagements here in the US. They are clearly directly doing the outsourcing on these contracts. Although neither discussion turned into an offer, my thinking was 'if you can't beat 'em, join 'em'.
I agree too that a dozen smart people dedicated to a companies true customers with skills which are being kept current combined with the pool of available contractors would likely do an excellent job of running an IT department. Instead what you see is a core of out of touch old boys (or girls in some matriarchal shops) protecting their turf against all onslaughts (particularly from the customers at one shop I recall but which shall remain nameless).


SCJP 1.4
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15632
    
  15

That article brought an incredible sense of deja vu. I swear he lifted it bodily from other places I've been reading lately - both the Mac/job security part AND the offshoring part.
While his arguments about management layers are a little muddy, they do remind me of points made in Fred Brooks' seminal book "The Mythical Man-Month" years ago.
I know this much, I'm mighty tired of hearing execs talk about "economies of scale" when a big bank is bought by a bigger one. Somehow I never noticed that the interest paid went up or the fees went down.
Which is why I keep my money at the local credit union these days.


Customer surveys are for companies who didn't pay proper attention to begin with.
Preeti Ramesh
Greenhorn

Joined: Jul 24, 2003
Posts: 18
Hi,
The article was really interesting, and I agree that when you offshore pure coding efforts to some other country, there is an extra interface layer etc. But that would be true in the case where only coding efforts are outsourced. To quote "...The Indian coders are treated as just that -- coders -- with all architectural decisions being made 12,000 miles away...."
I don't deny that this may be true in some cases, but definitely not in all. I have spent nearly 70% of my career working on offshore projects (when I was working in India) and we were always in charge of architectural decisions - and not just small companies, but a really big giant too (I don't think I can name the company, lest I get fired
I dont want to start a religious war here ...just offering a view from the other side!
peace,
Preeti
Al Newman
Ranch Hand

Joined: Mar 30, 2003
Posts: 716
Originally posted by Preeti Ramesh:
Hi,
The article was really interesting, and I agree that when you offshore pure coding efforts to some other country, there is an extra interface layer etc. But that would be true in the case where only coding efforts are outsourced. To quote "...The Indian coders are treated as just that -- coders -- with all architectural decisions being made 12,000 miles away...."
I don't deny that this may be true in some cases, but definitely not in all. I have spent nearly 70% of my career working on offshore projects (when I was working in India) and we were always in charge of architectural decisions - and not just small companies, but a really big giant too (I don't think I can name the company, lest I get fired
I dont want to start a religious war here ...just offering a view from the other side!
peace,
Preeti

Well Preeti, that means that the architectural team is isolated from the customer both in distance and time. Which means one of three things to me. Either there is an expensive 'interface layer' as mentioned in the Cringely piece or the project is on the way to failure.
A third possibilty is that the project was well specified before handover AND the specs won't change significantly during the life of the project. But what are the odds of that? In a 20 year career I've seen it once. And that system was never used, because the world had changed between inception and delivery, and the product the system was to support never made it to launch......


SCJP1.4, SCWCD
D. Rose
Ranch Hand

Joined: Apr 25, 2003
Posts: 215
I agree with article on following points-
1. IT department will have inertia to implement best solutions if their jobs are endengered.
2. Companies put very little money in training IT staff and upgrading its skills.Even IT companies themselves are reluctant to do that.
One thing to blame for this is fast changing IT landcape where there was a new mehodology/techology almost each day.
Other reason was that market wanted solutions at such a fast rate that it was easier for companies to directly look for exact skill set than training existing people and let them adapt.
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
Originally posted by Alfred Neumann:

Well Preeti, that means that the architectural team is isolated from the customer both in distance and time. Which means one of three things to me. Either there is an expensive 'interface layer' as mentioned in the Cringely piece or the project is on the way to failure.
A third possibilty is that the project was well specified before handover AND the specs won't change significantly during the life of the project. But what are the odds of that? In a 20 year career I've seen it once. And that system was never used, because the world had changed between inception and delivery, and the product the system was to support never made it to launch......

Are you trying to imply that most projects done offshore,
1. Fail OR
2. Get Built but never gets used OR
3. Incur a unjustifiable " interface " cost?
As for the third possiblity ( changing specs) , which is inevitable, i guess that is a common phenomena all around the world. Not sure how does it specifically apply to projects done offshore.
Preeti Ramesh
Greenhorn

Joined: Jul 24, 2003
Posts: 18
Hi Alfred,
The architects design the system to specifications irrespective of the location of the client. These specs are provided by a few high level project managers (who are sent to the client site for the entire duration of the project), and are familiar with the clients business process. They provide the specs after having conducted a suitable RA on-site.
The cost of having a few project managers posted at client site to do the RA, take the clients thru the prototype, negotiate and communicate changes in the specs is far lesser than employing a technical team of about 25-50 (or more) not all of whom are 'coders'
I do not want to dis-credit the article in any way. I am trying to bring out a point the author made which is not completely correct. And to clarify, most of these projects were in fact successfully deployed at the client's site. There was one odd case, but isn't that true even in case of on-site projects...
I am not lobbying for or against off-shoring (to whichever country), but if it was not a proven model, so many companies would not make such heavy investments in that direction. Its a matter of economics - in some time, countries like India, Russia, China will become more expensive (because of the high demand) and then it'll be some other place...
Al Newman
Ranch Hand

Joined: Mar 30, 2003
Posts: 716
Originally posted by karthik Guru:

Are you trying to imply that most projects done offshore,
1. Fail OR
2. Get Built but never gets used OR
3. Incur a unjustifiable " interface " cost?
As for the third possiblity ( changing specs) , which is inevitable, i guess that is a common phenomena all around the world. Not sure how does it specifically apply to projects done offshore.

Most large projects fail to some extent or another. Whether offshore or not. That is a verifiable fact.
"Get built but not used" is part of the failure rate.
Whether or not interface costs are 'justifiable' is irrelevant. They are a fact of life if you wish the project to succeed. If managers in the US commission a project offshore without budgeting for interface costs they are begging for the project to fail because of lack of communication about changing business conditions and requirements is THE major cause of delivering the wrong thing. This is a major risk even in the US where there are fewer cultural differences and time-based impediments to communication. It must be far higher offshore in India....
[ September 03, 2003: Message edited by: Alfred Neumann ]
Al Newman
Ranch Hand

Joined: Mar 30, 2003
Posts: 716
The cost of having a few project managers posted at client site to do the RA, take the clients thru the prototype, negotiate and communicate changes in the specs is far lesser than employing a technical team of about 25-50 (or more) not all of whom are 'coders'

I've seen this myself. The Indian PM's come out for a few weeks at inceptions, then go back and work with their team. Sometimes they return several times. But most of the time is spent with their team. Meanwhile conditions are changing on the client site with nobody there to monitor what is going on. Everything is formal communication, and that is a major project risk.
I am not lobbying for or against off-shoring (to whichever country), but if it was not a proven model, so many companies would not make such heavy investments in that direction.

Sorry, I can't agree with the rationality argument. Over 20 years in the software business I've seen management do so many really dumb things (both locally and strategically) that my belief in 'proven models' is attenuated. Take CASE tools for an example. I've seen heavy spending on CASE many times but the next time I see a payoff will be the first time. Usually CASE tools get in the way.
Preeti Ramesh
Greenhorn

Joined: Jul 24, 2003
Posts: 18
Everyone is entitled to their opinion depending on their experience. You have seen cases where PMs are on site only for a few weeks and then intermittently. I have seen cases where the PM(s) stay on client site for the entire project duration.
>..Sorry, I can't agree with the rationality argument...my belief
>in 'proven models' is attenuated...
I am not out here to convince you of anything. I am putting forward another point of view. This is supposed to be a discussion right?
As for how stupid / smart management is about this - time will tell, but its fun to make predictions anyway!
Al Newman
Ranch Hand

Joined: Mar 30, 2003
Posts: 716
Everyone is entitled to their opinion depending on their experience. You have seen cases where PMs are on site only for a few weeks and then intermittently. I have seen cases where the PM(s) stay on client site for the entire project duration.

In this case they tend to lose touch with their team then. You need both the local PM's staying on site AND some PM's shuttling between sites! Which is why it costs.
Preeti Ramesh
Greenhorn

Joined: Jul 24, 2003
Posts: 18
I'll leave it to you to work out the cost of having a couple of PMs working on-site + conference call costs versus employing a full team of 25-50 architects, sr. and jr. developers.
Al Newman
Ranch Hand

Joined: Mar 30, 2003
Posts: 716
Originally posted by Preeti Ramesh:
I'll leave it to you to work out the cost of having a couple of PMs working on-site + conference call costs versus employing a full team of 25-50 architects, sr. and jr. developers.

And I'll leave to it to you to work out the cost of not getting it right on delivery.
It seems to me that organizations with a proven track record of regularly bodging development at home are just going to bodge their offshore efforts as well. At possibly 60% of the cost, though after cleanup that may go higher.
The rational decision for many organizations is not to develop at all.
[ September 04, 2003: Message edited by: Alfred Neumann ]
Preeti Ramesh
Greenhorn

Joined: Jul 24, 2003
Posts: 18
Originally posted by Alfred Neumann:

And I'll leave to it to your to work out the cost of not getting it right on delivery.

Your assumption here is that all offshore projects are not delivered correctly...?
Originally posted by Alfred Neumann:

The rational decision for many organizations is not to develop at all.

That sounds rational.....?
This is getting way skewed... my original point was that not all Indian programmers are treated as 'coders' as stated in the article. I really don't have the time to get into why organizations with some track record shud not develop at all... :roll:
[ September 03, 2003: Message edited by: Preeti Ramesh ]
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15632
    
  15

Truthfully, the two WORST people to design a software project - whether outsourced or not - are the manager of the users and the manager of the software development group. They both operate on the observably false assumption that the users are actually using the system the way they're "supposed" to be using it. For that matter, they're making a BIG assumption when they assume that anybody even CAN use it that way in day-to-day work.
I learn a lot when I sit down and share a cube with end users. About real-world ergonomics, work flow in a live environment with the phones ringing and the myriad other diversions, and in amenities that suggest themselves after the project has begun to deliver that weren't even issues until people saw how things could now be done differently.
Jim Baiter
Ranch Hand

Joined: Jan 05, 2001
Posts: 532
Write your senators and public officials and encourage taxation for this offshoring. At least then it puts everything on an even groud and the best skills can win.
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Tim Holloway:
Truthfully, the two WORST people to design a software project - whether outsourced or not - are the manager of the users and the manager of the software development group.

For that reason, I often lump software developers in there, too. In fact, my book contains a sidebar on "Why developers should not write requirements." In short, we developers say, things like "ooohhh, I can add this cool feature" which it turns out costs a lot and has little value. Other times they simply don't understand the environemt in which the end user is working, or the larger process in which the software is being used.
That's not to say that developers shouldn't be involved at all, they should be, as should the the user's managers and the project manager, simply that the requirements should be lead by the end users, with everyone else weighing in with feedback, options, and other ideas.
--Mark
Sam Walker
Ranch Hand

Joined: Nov 06, 2002
Posts: 65
I think globalization will ultimately fail because of the differences in the culture, language and the day to day life experiences.
I�ve been calling Dell support quite frequently since I bought my new Dell computer in April, approximately twenty times, and all of my calls have been relayed to India. I have not spoken to a single American tech. support in all this time.
Recently I visited Dell�s �customer care� forum and was surprised how many people resented having to deal with non-American tech. support. And I thought I was the only one who was sensitive about the issue.
Al Newman
Ranch Hand

Joined: Mar 30, 2003
Posts: 716
Originally posted by Mark Herschberg:

For that reason, I often lump software developers in there, too. In fact, my book contains a sidebar on "Why developers should not write requirements."
That's not to say that developers shouldn't be involved at all, they should be, as should the the user's managers and the project manager, simply that the requirements should be lead by the end users, with everyone else weighing in with feedback, options, and other ideas.
--Mark

I'm doing requirements right now in conjunction with users, and what I'm learning is that they are trying to jam half+ of the functionality into the first of three releases. Unfortunately we're simply not going to have the manpower to do it.
But I generally agree with you Mark, subject to reality checks like this one.
[ September 04, 2003: Message edited by: Alfred Neumann ]
Matt Cao
Ranch Hand

Joined: Apr 03, 2003
Posts: 715
Hi Sam,
The problem with Dell tech support and other companies along the line is that people do not understand local accent.
Dell have a decisive point of contact. Have you think of draft a letter of complaint with your signature and 2/3 people that you see in the log, then snail mail to Michael Dell? Do not think yourself as troublemaker but think of career strategy. Really.
Regards,
MCao
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15632
    
  15

Originally posted by Mark Herschberg:

For that reason, I often lump software developers in there, too. In fact, my book contains a sidebar on "Why developers should not write requirements." In short, we developers say, things like "ooohhh, I can add this cool feature" which it turns out costs a lot and has little value. Other times they simply don't understand the environemt in which the end user is working, or the larger process in which the software is being used.
That's not to say that developers shouldn't be involved at all, they should be, as should the the user's managers and the project manager, simply that the requirements should be lead by the end users, with everyone else weighing in with feedback, options, and other ideas.
--Mark


Actually, if you'll note, I didn't address writing requirements. Obviously a written plan is important, but to produce a system that the users don't spend more time working around than using it's important to work with the users as the system is being produced. The XP philosophy understands this - instead of working for months to roll out a big monolithic system, break it up into milestones. Get the users a chance to see it forming and redirect the flow to fit them instead the other way around.
That's not as simple as it might be, since there's the potential for people to want to cram in new features and cause massive creep, just as there's the danger of people getting all bent because the system's not totally functional (some people just don't seem to be able to understand the words "That's not supposed to work yet", no matter how often you repeat them). But most of the really successful systems were not designed and implemented as a large-project effort. They started out as modest attempts to fill an immediate need. And just kept growing from there.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Cringley offshoring article
 
Similar Threads
Great realistic article on XML
Prediction for 2009!
Future of Sun ???
How microsoft plans to have complete control the internet
C#, Sharper Than Ever