I've been musing over the idea of oursourcing and how it may affect the software field. After some consideration, I think that at least some software outsourcing is bound to fail. The problem is that many people are under the false assumption that software is like other forms of engineering, and could be handled as such.
Well, is software like engineering?
I'm skeptical. I'm inclined to say no, however.
On the 1960's, NATO noted there was a software crisis in the quality of software. The resolution of this was that software development is a form of engineering, and it should be treated as engineering.
Unfortunately, this does not seem to be the case. Forty years later, we still have a software crisis. Software with bugs, security flaws, and unexpected behaviors is still very much a hallmark of the modern world of computers. There is an odd dichotomy to note. Both hardware and software have developed by leaps and bounds. Hardware, with few exceptions, is largely free of unexpected behavior. Software, however, is just accepted to have troves of problems.
Traditional forms of engineering in software do not work. The traditional, sequential form of software development (also known as the "waterfall methodology") requires that the major steps of software development proceed in order. In other words, analysis must be completed and be absolutely correct before design. Design must be complete and correct before coding, and so on.
This works in material engineering and manufacturing, but it does not work well in software. More contemporary notes suggest that iteration works better. Development "thrashes" back and forth between phases. Communication and feedback is of paramount importance, especially with the client. None of this happens in classical engineering.
I think that the root difference is that software development is not engineering. It is, instead, "reality construction." Engineering has the saving grace of allowing everything to be specified before hand in complete detail. If one is manufacturing gears for a car, one can specify exactly what each gear should be like. Facts such as size, shape, number of gear spokes are regarded as hard, objective, empirical facts.
Software, however, is not all fact. Since software is reality construction, people instead try to make realizations of conceptual ideas of things that they experience. With engineering, a car can be designed and constructed in only one way. Modeling a car with software, though, can be done in an almost infinite number of ways. Further more, the ways in which one can model a car based on software depends on how one subjectively understands a car.
This sort of subjectivity appears in software constantly. Specifications are often vague and incomplete (and perhaps even deeply contradictory in some not-so-obvious ways). Development methodologies vary. Understanding of software analysis and design varies (in fact, some authors assert that 95% of all object-orientated programmers do not live up to their title).
I find it hard to see how software could be outsourced effectively. Given the vagueness of requirements, and the tendency of software development to thrash back and forth, and also the requirement for constant communication to understand the reality being constructed, I don't see how it will work.
Gears for a car could be specified exactly with modern engineering. If this engineering were software, a requirement for a gear might look like this: "I need a gear for my car. It's a very nice car, and it's blue, and my puppy Toto rides in the back. The car has 230 horse-power, front-wheel drive, leather seats, and CD player that's broken. I need the gear by tomorrow, and it has to work perfectly, and also fix my CD player."