Chuck Allison’s interesting article “Software: Use At Your Own Risk”, (Better Software Magazine, July/August 2008, p. 9) discusses the risk inherent in software licenses compared to other warranties, reasons for the lack of quality in software and lists a sample of the code of ethics of the Association of Computer Machinery.Here are some reasons why I believe that the Government will not take effective measures to enforce more liability on software vendors in the short or long term (within the next 10 years).1. Consumers are instant gratification junkies. Consumers want things ‘now’ and are only mildly disappointed when they have small failings, so they do not officially complain so much as in other industries. We only have to look at the lines outside Apple Stores for the new iPhone to realize this. Many people were not even concerned that some phones had activation issues, as they understood that Apple would eventually fix this.2. No physical boundaries. License issues will differ in different countries and trying to enforce this will be an administrative and legal nightmare. Also, software can be downloaded from the Internet from anywhere. Even the attempted Chinese firewall was worked around within a day3. It is understood that software is never defect free. Maybe this is not the right attitude, however it is one we have ingrained into ourselves over the last 20 years as both users and developers. Microsoft’s famous Blue Screen of Death was frustrating for developers, but after a quick reboot, work continued – it was accepted (I say “accepted” as it was the most common OS used and there was no mass exodus to UNIX, or later Linux). Would the same attitude apply if your car broke down several times on your way to work?4. Software organizations do not learn. Many articles quote from references such as Brook’s ‘Mythical Man Month’. This book was written 30 years ago and many of the failings in Software Development back then still exist today. For example adding people to late running projects only makes them later.5. Perceived insignificant importance. We know the cost of failed software is in the billions, but other things in the public eye have happened to constantly keep this from being a primary concern. For example, The Gulf War, 9/11, Presidential elections, rising fuel prices and the current Fannie & Freddie crisis. Although software is involved everywhere the quality is not considered a public priority.One of the ethics Allison lists is “Contribute to society and human well-being”. Unfortunately, for Governments to pass legislation of the sort suggested by Allison, a monumental catastrophe will have to happen. We saw something along these lines with the introduction of Sarbanes-Oxley compliance following the Enron scandal. However, even if a plane were to crash due to software error, it is unlikely that even loss of life would be enough for the Government to pursue measures. In my opinion, the outcome would be that the airline and the manufacturer would have lawsuits filed against them, while the FAA and software producer would, at best, experience some bad press.

A couple of years or so ago, I had the pleasure of meeting Peter Coffee, who now works for Salesforce.com, but back then was Technology Editor at eWeek. We showed Peter our CQ2 product, and one of his comments went along the lines of “It’s only a matter of time before we start to see source code quality brought up in litigation cases.”

Rick Mueller is a DUI criminal defense lawyer who, on his blog, reproduced the transcript of a paper given by William C. Head and Thomas E. Workman Jr. at the International Council on Alcohol, Drugs and Traffic Safety in Seattle on August 30th. The paper is titled “An Analysis of ‘Source Code’ Litigation in the United States.” The transcript is long, but makes for fascinating reading, in my opinion, because it’s the first time I’ve come across a real example of what Peter Coffee was talking about.

I found their analysis, from a purely legal standpoint, of the state of software quality to be quite interesting.

Head and Workman start out by stating something that we all know to be true, but bears stating nonetheless: “All non-trivial software has defects.” That in itself is good news for an attorney, I guess. They go on to state that, unlike hardware components, which may simply have worn out, defective software works exactly the same way in every machine that contains the same software. So, you can’t compare results from two identical machines to find out which one has the defective “part”.

Head and Workman provide a kind of attorney’s guide to software development, in which they make some interesting observations:

Specialization and multiple handoffs
“The programmer who writes the source code is usually not the scientist upon whose science the machine is based,” they say, and then go on to point out that many others are involved in the production of the finished product. “With each handoff, opportunity for misunderstanding and mistakes in the final product, the source code, increases thereby degrading the quality of the product.”

Comments
Good programmers write comments, they say, but comments “often pose suspicions about problems that have been elusive and have not been specified and may not have been corrected. They may also contradict the instructions to the computer, as represented in the source code, meaning that either the comments are wrong, or the software is not correctly written.” You can’t argue with that!

Debugging code
If anyone’s ever left any debugging code in production software, look out: “Programmers often record information that will be helpful in resolving ongoing errors and defects. An examination of the source code will usually reveal extra steps that are not necessary to the computation of the results, but which will record information that relates to actual or potential error conditions. The mere existence of this kind of activity suggests that the programmers are trying to collect additional information in order to resolve problems they have seen, but have been unable to isolate and fix.”

Testing
This section includes an interesting analysis of why testing every path through even a small program would be impossible. Their example assumes a 1,000 line program with a 2-way control statement every 20th instruction. That gives a total of 1,125,899,906,842,620 unique paths through the code, which, even at one minute to run and check the results for each path, would take one person a total of 2 billion years to complete the testing.

Defect rates
The good news is, they tell us, that we can estimate the number of defects in any piece of code by applying the average of 25 defects per 1,000 lines of code. Thus: “The estimated number of defects is calculated by multiplying the number of lines of code by 25, and dividing that product by 1,000.”

Code reviews
“A computer scientist,” Head and Workman tell us, “preferably with a background in verifying software quality, can frequently find defects in software by “reading” the source code. In addition, source code may be reviewed automatically through automated review of the source code.” “When a DUI-DWI defense attorney requests the source code for a Breath Testing Machine, it is with an aim to conduct a “code review” to look for defects.”

There’s nothing in here that we don’t already know about. But, I find it intriguing that the legal profession is starting to familiarize itself with these concepts with a view to using the weaknesses in our quality processes to question the integrity of information and analysis provided by software.

A quick thought for a Friday afternoon. Mary Jo Foley reports at ZDNet that Microsoft is starting work on the “Kitchen Client” version of windows. “Among the features Microsoft is planning to make part of its forthcoming kitchen computing environment are a family calendar, recipe center, entertainment features and a shared bulletin board,” she says.

Is that burning toast I smell?

Going through late teenagehood in England, my first car was a Mini. Not the fancy, BMW-in-sheep’s-clothing that goes by that name these days, but an original, 1964 vintage Alec Issigonis-designed model with an 850 cc 4-cylinder engine and rubber cone suspension that cornered like it was on rails.

The only maintenance that car required, aside from the occasional oil change and a squirt of WD-40 every time it rained, was a change of spark plugs and a check on the points gap. You could do that in about 5 minutes with a screwdriver and a feeler gauge.

This all came flooding back to me as I dropped my car off at the dealership for its first (7500 mile) service this morning. The service technician told me that the service would take a bit of extra time, because there were some recalls that needed to be attended to. When I asked whether it was anything serious, he told me: “No, all software updates”.

I wonder how long it will be before our cars are able to download and install their own software updates - after which, hopefully, they won’t need a reboot - at least not while driving on the highway.