Posted 8:13 PM by Floyd

Evan Kirchhoff blogs about the California grocery worker strike, and about the trend toward automation and elimination of manual labor jobs. The bulk of his post is typically perspicacious, but I disagreed with this statement:

Hence, in case it needs to be said: of course I approve of "outsourcing" tech jobs like mine to foreign countries. I accept that all currently lucrative programming skills will collapse to zero value over the next 5-20 years ...

It is possible that certain "programming skills" will collapse to zero value; in fact I would not be surprised if these skills had a low value right now. That is because the "programming skills" I have in mind-- writing code to cause a computer to perform certain actions according to a specification -- are not the critical path for software development jobs. Software developers will be in high demand, and will command large salaries, regardless of whether there are three million people or three hundred million people who can write a for() loop.

I am not saying that coding skill is unimportant; rather that coding is a necessary but not sufficient requirement. It is rare for poor code to kill a software project. One common factor that makes projects fail is when the programmers put their pieces together and find that they do not integrate. Obviously the risk of integration failure is not going to lessen if your team is split between two continents.

Another mistake that causes projects to go bust is the engineers' failure to understand the problem. In many products that I have worked on, the hardest problem was simply to figure out what was the problem. A software product that solves hard problems -- which is the kind of product that people are going to pay good money for -- typically has complex features, and even more complex interaction between those features. Understanding the features is often beyond the comprehension of many engineers. It's extraordinarily difficult to write this knowledge down -- usually the resulting literary effort is incomplete, or confusing, or coma-inducing. So engineering teams rely on experts to explain difficult concepts to other team members face-to-face. It's hopeless to try to accomplish these explanations via email, and difficult to do so over the phone.

Ambitious software projects, especially projects that attempt to use new technology, have another characteristic that makes it difficult to outsource them: Initial work on such projects are prototypes that uncover shortcomings of the design, and as a result the design (and features) undergo considerable change. Team members who are geographically separated will find that their understanding of the project diverges more and more from the evolving current design. (If the development is performed entirely overseas, then the outsourcers will find that what they get back is not what they asked for.)

In the last ten years I have had many opportunities to view attempts to outsource work to India. Here, in no particular order and with details redacted, are my observations:

• An Indian subsidiary was created to perform data entry. For the first year or so absolutely no work was done. The head of that organization was fired, and the new boss proved to be much more competent. Eventually the data entry subsidiary did a fair amount of good, cheap work.
  
  
• I wrote a quick-and-dirty tool to perform unit testing of my product's Java code. Our company's Indian development operation started developing a bigger and better version of this tool. This software was worthless, and had to be rewritten by some of our American developers.
  
  
• My employer had a large software development organization in India. There was considerable effort put into training the Indian engineers; many of the American workers would take trips to India, and most Indians would spend a few weeks working in America.
  
  Results were mixed. Some products were completely done in India and seemed to work reasonably well. Our product had co-development in both India and America. The majority of the developers were in India, but they did very little lasting work. Often quality was a serious problem. I am not surprised; if your motivation for hiring someone is that they are cheap and expendable, why would he care about the long-term viability of his work?
  
  
• Our team outsourced changes to be made to some of our application's HTML pages. Despite the fact that the work was well-specified, limited in scope, and near-mechanical in nature, the quality of the work performed in India was very poor.
  
  
• An Indian developer was helping a customer with a bug. He was having problems using some UI framework code that I had written. He would email me use cases, and I would try them out and email him my suggestions. Executives who know nothing about software development call this "24-hour development", the idea being that at any given moment, some employee of the company will always be hard at work. Here is what our email conversation was like:
  
  
  
  
  • I think the X is wrong.
    
  • Do you mean the X in Y or the X in Z?
    
  • Oh, the X in Z.
    
  • Okay, try setting your foo to bar.
    
  • It doesn't work.
    
  • Please send me your config file.
    
  
  
  The problem is that if you need to ask a question via email of someone twelve time zones away, you will not get a response until the next day. We wasted a week working out problems that could have been solved in half an hour face-to-face. I doubt if the customer was impressed with this five days of "24-hour development".
  

(By the way, I am not anti-Indian. I have worked with many fine Indian engineers, and they performed well when they were here in America and not ten thousand miles away. Also I am probably overemphasizing failures, which are more memorable than successes. One India QA group did quality assurance on a Japanese port, even though no member of the team spoke Japanese. That's the kind of war story I'm going to tell to a fellow developer, but it really has nothing to do with latitude or longitude. Nobody is going to bother with a tale such as "we had a team working in Bangalore on X product and ... it worked just fine.")

It is true that there are a lot of people in the tech industry worried about outsourcing to India (and other countries). Here are some reasons why I think they are overreacting:

• The tech industry just went from boom to bust. A lot of layoff victims are looking for work, and outsourcing is a convenient scapegoat. But many of these people should never have been working in software development in the first place, just as most of the people who moved to California in 1849 were not expert gold panners. The dot-com bubble had very little to do with technological progress, and very much to do with a whole lot of pigs trying to get their noses in the feeding trough.
  
  
• Indian software development, especially in Bangalore, has become so successful that good engineers are commanding more money. This is vague and anecdotal, but when I was first exposed to outsourcing in the early 90's, we would hear about how our company could get ten people in India for the same cost as one person in America. Now the ratio is expressed as three to one.
  
  
• Outsourcing is a fad, and like all fads will run its course. American companies will discover the drawbacks that I have listed above. Here is an example from today's paper: Dell is moving its customer support from India back to America.