|The Declarer (Floyd McWilliams' Blog)|
Monday, November 24, 2003
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:
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:
(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: