I am a software developer that is currently on the market, looking for either contract or full-time work, so I'm no stranger to this issue. However, my viewpoint might surprise the so-called Pissed-Off Programmer types. I think the answer, as in most cases, lies in education, and I'm not talking about educating technology people. I'm talking about educating the corporate executives making these outsourcing decisions.
In my experience, I can say with confidence that many companies make the decision to outsource based on the idea that "farming out" this work is like farming out manufacturing work. Companies having trouble with the project management side are particularly prone to this way of thinking, and most companies suffer in the project management area when it comes to technology because the technology explosion happened so quickly that business processes for developing software are still immature. The result is, companies that cannot manage a technology project team spread over a building end up thinking it will be easier to manage that team spread over the globe.
For some projects, the outsourced pieces are what I like to think of as "programming boilerplate", or "code monkey" work. These are things that have been done a thousand times and are mostly independent of a particular project, industry, architecture, deployment strategy, etc. For instance, if you needed an algorithm (a series of predetermined steps, no matter how complicated, is an algorithm) coded, then boom, farm it out and you'll realize that 25% to 40% cost savings these companies love to tout. You get back the code, you know exactly where it begins and ends in the overall picture, where it needs to run in the greater scheme of things, bingo, bango, boingo...it's money in the bank.
However, if a company's trying to farm out creative work, it realizes that up-front cost savings, but these quickly get eaten up by the increased cost of project managers arbitrating technology issues over 12 time zones, business analysts drafting formal specs, and architects following rigorous processes, all of which are required to make outsourcing work. Companies farming out what I'll term "creative" development work invariably fail to do these things so they can indeed carry forward their 25% to 40% in up-front savings to the bottom line...on paper, anyway. They result, though, does not integrate with the rest of the project. The code provided from the outsourced team has rarely been designed as a controlled, extensible, and pluggable part of the overall architecture by the American project managers and architects, because that's H-A-R-D to do. This *is* the reason technology teams require such intimate communication that's impossible with an outsource team...it's cost prohibitive to make every subsystem you'd like to outsource completely modular.
Ok, you might say, but what about the claims these companies are making that in many of the cases the code generated by Indian outsource teams are actually *better* than what is being written at home? Well, this breaks down into two parts. One, throughout the '90s many people got into programming for the easy money, and many of these people are quite frankly tech babies that couldn't code their way out of a paper bag. The Indian coders are, because of what they have to overcome in a more poverty-stricken country to attain higher education, quite simply better than this half of the coding community. These American code monkeys seem to think that learning a list of keywords and the basic flow control of a programming language makes you a software developer. No, I say, it only makes you capable of banging out the linux source if given a roomful of other code monkeys, a good supply of typewriters, and a billion years. Real software developers understand the why's behind standards. Real coders know that the long-term needs of business will be served by writing truly *extensible* systems. Extensibility is a concept more foreign to a code monkey than the Indian rightfully relieving that person of the
Slashdot Mirror
I am a software developer that is currently on the market, looking for either contract or full-time work, so I'm no stranger to this issue. However, my viewpoint might surprise the so-called Pissed-Off Programmer types. I think the answer, as in most cases, lies in education, and I'm not talking about educating technology people. I'm talking about educating the corporate executives making these outsourcing decisions.
In my experience, I can say with confidence that many companies make the decision to outsource based on the idea that "farming out" this work is like farming out manufacturing work. Companies having trouble with the project management side are particularly prone to this way of thinking, and most companies suffer in the project management area when it comes to technology because the technology explosion happened so quickly that business processes for developing software are still immature. The result is, companies that cannot manage a technology project team spread over a building end up thinking it will be easier to manage that team spread over the globe.
For some projects, the outsourced pieces are what I like to think of as "programming boilerplate", or "code monkey" work. These are things that have been done a thousand times and are mostly independent of a particular project, industry, architecture, deployment strategy, etc. For instance, if you needed an algorithm (a series of predetermined steps, no matter how complicated, is an algorithm) coded, then boom, farm it out and you'll realize that 25% to 40% cost savings these companies love to tout. You get back the code, you know exactly where it begins and ends in the overall picture, where it needs to run in the greater scheme of things, bingo, bango, boingo...it's money in the bank.
However, if a company's trying to farm out creative work, it realizes that up-front cost savings, but these quickly get eaten up by the increased cost of project managers arbitrating technology issues over 12 time zones, business analysts drafting formal specs, and architects following rigorous processes, all of which are required to make outsourcing work. Companies farming out what I'll term "creative" development work invariably fail to do these things so they can indeed carry forward their 25% to 40% in up-front savings to the bottom line...on paper, anyway. They result, though, does not integrate with the rest of the project. The code provided from the outsourced team has rarely been designed as a controlled, extensible, and pluggable part of the overall architecture by the American project managers and architects, because that's H-A-R-D to do. This *is* the reason technology teams require such intimate communication that's impossible with an outsource team...it's cost prohibitive to make every subsystem you'd like to outsource completely modular.
Ok, you might say, but what about the claims these companies are making that in many of the cases the code generated by Indian outsource teams are actually *better* than what is being written at home? Well, this breaks down into two parts. One, throughout the '90s many people got into programming for the easy money, and many of these people are quite frankly tech babies that couldn't code their way out of a paper bag. The Indian coders are, because of what they have to overcome in a more poverty-stricken country to attain higher education, quite simply better than this half of the coding community. These American code monkeys seem to think that learning a list of keywords and the basic flow control of a programming language makes you a software developer. No, I say, it only makes you capable of banging out the linux source if given a roomful of other code monkeys, a good supply of typewriters, and a billion years. Real software developers understand the why's behind standards. Real coders know that the long-term needs of business will be served by writing truly *extensible* systems. Extensibility is a concept more foreign to a code monkey than the Indian rightfully relieving that person of the