"[W]hy are programs so buggy? A general answer has already been given: because it is human nature to push until we get into trouble -- and then blame our tools. We load the elephant with feathers until the elephant collapses, whereupon we conclude that feathers are too heavy for elephants. No matter how amenable software is to our efforts, it can overwhelm us if we pile the code high enough -- and we often do, because it's so fatally easy. But the special reason for software's bugginess is that we almost never demand that it be bug-free (I use "demand" here in the economist's sense: not just desire, but desire backed up by ability and readiness to pay).

"Software manufacturers are rational economic actors; if they can sell us software without going to the expense of thoroughly debugging it, they will. The copy of Microsoft Word that occasionally drives me crazy cost around $200; if Microsoft had been forced to debug it thoroughly before releasing it, its price would be closer to $2,000. Would I pay that much for a version that I could be sure would never crash at a critical moment, losing hours or days of my work? Probably not; apparently, I don't value my sanity that highly. I am neither blaming anyone nor apologizing for anything; I am simply reporting Microsoft's behavior and mine, in the belief that they are typical of just about all software developers and computer users. In a word, we have buggy software because we consumers won't pay what effectively bug-free software would cost.

"The reasons why software is almost always buggy are not inherent in the technology and thus inevitable, but spring from human choices and practices that we can understand and could change if there were a compelling reason to do so. Those habits include piling the code on until it overwhelms us, and taking our chances with buggy software in order to get it more cheaply. Both problems could be overcome if we wanted to overcome them badly enough."

[Mark Halpern, "Buggy Software and Missile Defense," The New Atlantis, Number 10, Fall 2005, pp. 47-57.]