The Code Bug That Bites

May 1, 2013

It may come as a great “shock” to most people almost every software or hardware contains “bugs” or errors. For the purpose of this paper I will focus on software, but the same ideas may apply to hardware as well. This first record of programming error is attributed to Ada Lovelace, the first computer programmer on the analytical engine. She noted that the order of cards inserted to the machine may be off and this might result in an error. In 1946, Grace Hopper encountered a malfunction that turned out to be a moth inside an early electromechanical computer that caused a literal bug in the hardware. Weather it is an actual insect or other types of error, software and hardware may malfunction and deviate from the original programmers intend. End-users encounters errors almost every day. I am sure there does not exists a user who has not come across some form of software error. Weather they acknowledged the "bug" or not, the software most certainly does. Over the past decades, numerous times developers and cooperation alike are blamed for software malefaction. The results of these bugs range from a user smacking the monitor, to lawsuits and even the cost of human life. The question that arises is who to blame? Over the past decade my view has changed on what should and shouldn't be the developers responsibility. The following is my own opinion on the matter.

Before I wrote my first “Hello World!” program, I was an end-user like many others. As an end-user, we often use the software and get annoyed when it doesn't work properly. Corporations and developers go to extreme lengths of effort to develop bug-free code. Yet many bugs are not discovered until after the official release. Updates are often issued to fix certain bugs, but many bugs remain doormat in the system. If a problem is localized to a small amount of users, it might take a while until the problem is addressed by the developers. As an end-user, we expect a perfect product. No one wants a software that contains bugs, yet every software has them. When bugs are encountered, we look for whom to blame, often the developer or the company behind the software. Corporations and developers learned long ago that in order to protect their interests, they should have a disclaimer issued with the software. Over the years, these disclaimer grew longer to protect the software issuer from all sort of liabilities. As an end-user I never (and still don't) read any part of it. We tend to just click the “I agree” button and move on. This is not a good practice, but it is more practical than reading. For example, Windows 7 Home version EULA is about 12 pages long. In addition to the length, companies typically reserve the right to change it from time to time. In some cases, users don't even see the agreement as most of the software comes pre-installed on the machine they bought or are issued by their employer.

There are many reasons as to why companies choose to hide behind long disclaimers. For one, they have enough money and they pay their lawyers good money to protect them from lawsuits. Private developers might not have the same luxury, but they also want to protect themselves just as large corporations do not wish to be liable. Sometimes, people might seek out to sue a large corporation for damages, just because of the money it might entail in the end. Other times, it might be because of an actual fatality directly from a faulty software. Software “bug bites” (that is when a bug occurs) differs and are individual per case. In some cases it is very clear where the faulty bug is, where in others it might not be so cut and dry. When “bugs bite”, people often look for whom to blame when things go wrong. Even if the user was at fault all along.

Over the past years my views on the matter have changed significantly. I used to believe that developers, individual or corporation, must be required to develop bug-free software. As I learned more about the effort it takes to produce such software (or close to). I now believe that developers cannot be liable for bugs as much I used to believe. It is improbable, if not impossible, to produces a complete bug free code. So what can we do? In my mind there are three distinct cases of buggy software that can be classified as follows:

The first case is when a bug is known to exist within before a software is released.
The second is when a bug is discovered after the initial release.
The third is when a bug becomes a feature.

The third case is the easiest to explain. Sometimes bugs are discovered to be beneficial and produce a good outcome. In such cases, the bug is often incorporated into the software and no harm is done. The first two cases are harder to examine. In the first case, a developer is directly liable, in my opinion, if they know that there is a possible issue with the software. For example, if I were to write a software for a bank, but know that there is a trap door that might grant an unauthorized user access to every bank account, I am directly liable. The reason behind it is that I know there is a problem that might cause harm, yet I have not done anything to stop it. In fact, if such a bug is exploited and bank account information is leaked, guess who will be first to have a knock on their door? In the second case, that is that a bug is discovered after the release, I believe that a developer cannot be expected to be liable. Going back to the same example, only that this time I was not aware of such bug, I cannot be expected to be liable if I did not anticipate it. I am using the word anticipate intentionally, because I believe that as with every software, it is my responsibility to check for bugs prior to the official release of the software. If I, as a developer, do not check for every reasonable scenario prior to the release, in my mind I am not doing my job correctly. This is not to say that every situation possible should or could be considered. Code is very complex and it is hard to anticipate every situation an end-user might encounter. However, there needs to be sufficient testing to an extent that the software might be used and beyond. If I am writing a program for school, program testing might be very small and limited to a sample input-output. However, if the software is to be used to monitor heart rate in an ICU, the software must be completely checked before the release, or at least it should. Doing so might not create a complete bug-free system, but will reduce the likelihood of a critical bug tremendously. Some people also suggest that testing might reduce the future upkeep cost of software, but that is an entirely different topic.

My individual opinion might be nice in theory, but in reality it fails almost every time. As time goes by, new information might be presented to me that may alter my opinion. As it stands, there are many factors to take into consideration while developing software. In many cases it is easier to write what the software cannot do, or when it might fail, than to fix the problem. In other cases, there might not be the manpower to fix the problem, or a deadline that needs to be upheld, so certain bugs are left untouched. Some developers might even hide their knowledge of a bug just to avoid the liability or the work needed to fix it. After everything is said and done, software or hardware is just another tool. An end-user should see no difference between a hammer or software. Just like a hammer might break if using it incorrectly, one should not be liable if the software or hardware was used incorrectly. Furthermore, just like there is no user disclaimer for a wrench set, there needs not be one for many, if not all, digital applications. This is not to say that if I try to use a brand new hammer and it breaks the first time I won't ask for a new one. However there are certain things that are outside of reasonable use and can not be anticipate by developers. After all, an operating system contains millions of lines of code. I doubt anyone can examine all of them and find the odd character that might cause a problem somewhere down the line.

What are your thoughts on the matter? Are developers liable for software bugs?

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

You Might Also Like