Let's Not Get Ahead of Ourselves
There's an article on Baseline Magazine which presents some amusing anecdotes of software driven appliances such as dishwashers. Anyone who's seen their computer lockup or drop out to the "blue screen of death" will either enjoy this article or find it foreboding.
The article also discusses in great detail the problems one customer has had with his Windows XP powered BMW. Though, to be fair to Microsoft, it doesn't seem like the problems are the fault of Windows but the software which interacts with the car's computer systems.
Nevertheless, I'm reminded of a story which stated that Microsoft was getting into the out-patient monitoring business. They were going to team up with another company and build systems that would monitor the health of a patient in their home. Should a problem occur, the system was supposed to phone in an ambulance.
The title of that article: "Gives New Meaning to Blue Screen of Death."
I can't help but think that software isn't there yet. It's not that we don't have bright developers: it's that these developers don't have the right tools. Imagine asking an engineer to build a new breed of space shuttle using nothing but chisels and hammers..and, oh yeah, we're gonna need that by the end of Q2. Thanks.
As an aside, at last count, the space shuttle had about 420 kilobytes of code developed over 30 years. The c4.net Web site is about 1,500 kilobytes, and that doesn't include the software that actually serves up the site. It was programmed in spare time over the course of two years. Though it's been live for several months, we still find the occasional bug…and, oh yeah, it doesn't fly space shuttles.
Baseline delivers industry news to project managers. They're concerned with how to prevent bugs which crop up during software development from finding their way into the final product. Ironically, one company's solution was to eliminate post production "quality assurance" tests. Instead, they have developers turn in all code at the end of the day. These practices are commonly referred to as "nightly builds" and "unit testing."
So, hear we are. It's 2003, and our software isn't even as reliable -- or at least not as easy to fix -- as a mechanical typewriter. Now, we're going to take that same code and "repurpose" it as GPS based navigation systems in cars; systems monitoring software in homes; and, of course, computerized cash registers, bookkeepers and accountants in small business. Yet, we're still surprised to find that these products don't work as advertised.
I think we need to start demanding higher quality, not more features, from the software we use. Some people have proposed regulating the industry. If electricians have to be licensed, why not the programmers who write the software which controls the appliances? I have to have a license to drive a car but not to write the software which controls the car.
Or maybe we just need to test the validity of end user license agreements (EULAs), those screens that pop up before you install any piece of software, those screens which make you agree to waive all your rights before you can use a piece of software. In a society with as many lawyers as we seem to have, why is it we can't sue software companies for misleading advertising and lost work from computer crashes?
There are many possible solutions to the overall poor quality of software. As software becomes more pervasive and intrinsic to our daily lives, we will need to begin implementing these solutions. We should expect more from software and computers in general, not less. That was the promise.