The ultimate manifestation of the SMFs within industry is the current offshore outsourcing (“Offshoring”) fad. To find the cheapest programmers, one moves operations to the lowest wage countries he can find. The hype on offshoring is so frenzied that experience in offshoring has become a mandatory requirement for nearly any senior level computing management job.
Offshoring often gets marketed with ridiculous claims. These include “24-hour software development” where programmers in the U.S. start working on a problem and, when they go home for the night, programmers on the other side of the world pick up they left off – something not practicable until Star Trek mind transfer machines become available. There was even serious discussion of the ridiculous concept of putting programmers literally offshore in cruise ships.
There is much fear that the bulk of U.S. computing will eventually be moved overseas, just as the manufacturing of sneakers has been. Under the new model, the U.S. will retain the high-level system design and architecture while the “low level” programming jobs will go offshore.
I do not share this grim view – at least for the long term. Although, over the near term, I expect much pain for U.S. workers until the offshore lemming parade runs its course, herded over the cliff by consultants and hucksters who have established themselves as offshoring experts.
Who would have guessed a half century ago that it would be nearly impossible to find a “Made in the U.S.A” sneaker today? Still, there is a major difference between making sneakers and making software. A U.S.-based shoe company can have its creative people in the U.S. They can create the designs here. They can build the prototypes here. Then they can ship those designs to Timbuktu to have low wage workers turn out sneakers at the lowest possible worker-per-hour manufacturing cost.
Which brings us to a key reason why software is nothing like making sneakers: For software there is virtually no manufacturing cost. Nearly all the cost for software comes from the development stages prior to production. Stamping out CDs of finished software is nearly an incidental expense in the overall costs.
For years companies in the financial industry could have saved money on labor costs by moving software development from New York to Peoria. Peoria has many advantages over going “offshore,” including fewer time zone changes, no visa and travel issues, more stable infrastructure and better communications. Still, the heart of the financial software development is New York. The reason for this is the need for software developers to be close to their users. To do software development effectively, your developers have to work closely with the people who will eventually use the software. New York is where the financial people are so New York is where the financial software developers are. If Peoria was too far to move 20 years ago, why is moving half way around the world any better today?
Last year I encountered an interesting example of the culture clash caused by offshoring. I called my credit card company to get a copy of a bill. I was unable to convince the overseas agent of the need for me to get this before April 15th. Though not a software offshoring issue, it illustrates the lack of perspective you may be inheriting through offshoring. (This is now my former credit card company.)
Remoteness becomes an even greater issue as computing grows in importance for business. It becomes more difficult to anticipate market changes when your computing organization is removed from its industry and the organizations it serves. When the operations are offshore, you eliminate any possibility that your programmers will be sharing ideas with marketing over lunch.
Of course in the ideal offshoring model, the high-level design work remains in the U.S. Then where do the skills to do high-level design work come from? If all the programming work is moved overseas, there will be no place to learn the software development process and reach the point where one can be a software designer.
We see the same narrow view on Wall Street where they believe they would be able to be the center of deal making if the U.S. offshores everything but Burger King and lawn services. I know of a management consulting company whose “offshoring practice” produces glowing reports on the benefits of offshoring to the U.S. economy. The same company has produced a report on why America needs to protect Wall Street from being offshored. (Would America be better off with a solid manufacturing base and Wall Street offshore, or offshored manufacturing and a Wall Street in need of bailouts?)
The greatest problem offshoring faces from a purely software development standpoint is one of culture. Ask yourself, why is the United States, by far, the largest producer of commercial software? There has to be something intangible in the U.S. that causes this. That intangible is that Americans interact in a manner that is contusive for software development.
For example, suppose an American programmer forgets, let us say, the name a Unix shell command. He knows what it does and has used it in the past but today he cannot remember the name. The American programmer immediately asks the person in the next cubicle, “What’s the name of the command that does…” He gets the answer in 2 minutes and feels no shame for asking such an easy question. In many countries a programmer in the same situation will spend a week going through manuals to find the answer. Asking the person next door to get the answer would be humiliating.
If you call technical support in the U.S. and the person you get on the line does not have the answer or cannot get it in a short period time, that person will usually escalate your call to someone else who is more likely to know the answer. Offshore technical support is completely different. I have spent hours on the phone with overseas technical support people who refused to escalate problems even after it was clear they had no hope of solving the problem.
This cultural element is not unique to America. There are other countries that have it to varying degrees. However, everything I have seen so far suggests that the cultural intangible for software development found in the U.S. is not to be found in the current “offshoring” destinations.
A common problem in offshoring is planning for contingencies. The pattern in the industry is for companies to bring in their offshore outsourcing company; have their employer train their replacement; and fire their current employees.
What happens when the offshoring fails and you need to end it? There is no incentive for the offshoring experts you hired to plan for such a contingency – if your offshoring turns into a disaster, they are going to be gone before the salvage operation begins. All the internal expertise your company has built up has gone elsewhere or been transferred to your outsourcing vendors (available to be sold to your competitors). Your company will have to rebuild from scratch, an expensive process.
Offshoring runs into basic economics. As more work moves offshore, the demand for overseas programmers will grow and the costs will rise, something we are already seeing.
I have history to back me up on this view of offshoring.
One of the signs that I am getting old is seeing the computer industry recycle old ideas (usually with new names) and acting as though they were new. Machine independent “byte-code” and SOA are example of such rehashed concepts. Some history helps put offshore outsourcing into perspective.
Go back to 1989. That year two large American companies announced they were going to “outsource” their computing operations. They would no longer be in the computer business. Instead, companies would expertise in computers would provide the services.
Outsourcing became the biggest thing in the industry. “CIO of the Year” awards followed. Management consulting companies set up outsourcing practices; Industry analysis groups started running seminars on outsourcing; and hucksters started adding “Outsourcing Consultant” below their names on their business cards.
Over the years, outsourcing fizzled out – although not entirely. Outsourcing continues in selected areas, such as technical support and network management. However, the large-scale outsourcing that was hyped as way of the future nearly disappeared.
Now “outsourcing” is back in with “offshoring.” The management consulting companies have set up “offshoring practices”; the offshoring seminars are back; and so are the offshoring experts. Instead of outsourcing to IBM, outsource to IBM India and all will be different. Déja vu all over again.
We are already starting to see the cracks in the offshoring fad. Online forums contain discussions of how promised savings from offshoring are failing to materialize. There are accounts of companies charging costs of runaway offshored projects to domestic projects to satisfy management calls for offshoring success. More people are starting to openly question the offshoring dogma.
This not to say offshoring is bad in itself but rather that it only makes sense in certain circumstances. Objective examination may find that certain projects are better done overseas. For many technical challenges, the leading expertise is not in the U.S. When faced with this kind of problem it makes perfect sense to go offshore. However, offshoring because of Wall Street expectations or because the SMFs show you can get three programmers overseas for the price of one in the U.S. is simply moronic behavior.
Just as with outsourcing, I do not expect offshoring to go away entirely. Companies will go overseas to gain access to specialized expertise. Overseas vendors will compete with domestic vendors. However, the U.S. software development industry will not pick up and move next door to the sneaker factories.