Why Software is Never Flawless

A civil engineer once told me that if bridges, roads and buildings were constructed with the same level of quality and integrity as a software program, society would cease to function after the first heavy windstorm. I have often wondered why we tolerate the abysmal record of software failures and glitches, given the fact how information technology is the engine of commerce, backbone of civilization, and all that jazz. But seriously, for those of us in the business, whether toiling in a back office sweatshop batch processing bank statements, or designing the next great killer app that will change the way information is processed forever (read 3 to 5 years), failure is quite common; more common than in other disciplines. Even though there has been an improvement in the number of successful software projects due to improved processes, skill sets, and management, there are still two main causes for the demise of a software project:

The software does not do what it is intended to do – missed or misinterpreted requirements;
The software cannot do what it is intended to do – shoddy or rushed development

Imagine this discussion between two architects:

Architect 1: Hey Bob, how is the new museum construction down in Florida coming along?
Architect 2: It’s going ok Jane. Although the glass ceiling we installed can only withstand a 15 km/hr wind. Anything above that, the whole shebang will collapse inward.
Architect 1: Jesus! And you guys are still going ahead with this?
Architect 2: Yeah, the timelines were tight but we have a contingency plan in place. If it gets too windy, we’ll move the dinosaur bones and the Faberge Egg exhibit to the basement. If the ceiling does come down, the museum will refund admissions for the day. Then we’ll come in and patch up the ceiling with a new stronger glass that we wanted to put in to begin with, but couldn’t because we didn’t have the time or money. Plus the insurance will cover the costs of installation and materials.
Architect 1: Wow, you think of everything!

Or between a plumber and his customer:

Plumber: Ok, I have your toilet installed.
Customer: There is no water in the bowl. How come the tank doesn’t have any flush mechanisms? It’s empty!
Plumber: Oh, you mean like the float ball? That’s part of the upgrades to Toilet 2.0. It will be released next quarter. But you’ll get it for a discount when it comes out.
Customer: Alright, sounds good.

Obviously these scenarios are totally ludicrous. Yet, when it comes to many software systems, this is commonplace. Decisions are made to implement erroneous software, and mitigate the fallout after. Why is this?

Cost of developing a quality software product can be quite high. Unlike hardware, or any other physical entity, one can never test all potential software defects, and therefore software is often shipped to the end customer, bugs and all. The activities that are required for good software QA are listed in the following article. http://www.badsoftware.com/plaintif.htm. As one can imagine the costs add up, which leads to my second point….

Why bother? Often there is a more lax attitude towards software quality than hardware quality because of the reason listed above. The costs to produce the perfect software could lead to release delays, or software that is too expensive for the intended market. Decisions are made to go with a less-than-optimal software application in the cases where there is little or no legal liability, or consumer backlash for doing so. So until it is demanded by a court of law, or by Adam Smith’s invisible hand (which could slap a buggy application like it was one of the Three Stooges), the failure of application software to do exactly what it is proposed to do in an effective manner will be a fact of life, unfortunately.