To Err is Human

To err is inherent to human beings. Even the human being may be considered an error in itself.  Unfortunately, in these days nobody wants to recognize his/her errors. We just have to take a look at politicians making wrong decisions in government, managers loosing money due to bad strategical policies, referees in sports, our relatives and friends in their personal decissions, etc. And of course, ourselves in our daily context. The reason is that errors are usually perceived by a majority of people as a weak point of the person that caused the error, and... everybody wants to be/appear flawless.

But, IMHO, that attitude is also an error, because in every role we play in our lives (as managers, students, engineers, doctors, programmers, architects, etc.) we are supposed to err sometimes. No exceptions. So, to me it is very important to recognize the errors we make. So, in this post I'm going to post some references to resources that are related to errors in software.

First of all, it is good to know what are the most frequent errors we can make when developing software. This web page describes a catalogue of software weaknesses in source code and operational systems. It also offers the current list of the 25 most common errors in software that lead to most part of vulnerabilities in programs.

Once we are aware about what are the errors we can make, the next step is try to avoid them when developing. Test Driven Development (TDD) is a well-known technique to follow when reaching the development phase in software construction. It is encouraged by agilists, but of course it can be applied to any software development process. Basically, it consist on repeating the following development cycle:

1. Write the necessary test cases that define a new functionality that is going to be added to the software in development;
2. Implement the required functionality;
3. Pass the test cases developed in the first step;
4. Refactor the code to make it adequate with regard to code quality standards.

As we have seen in the fourth step of TDD, when trying to avoid errors in the development phase, it is a requirement to program in a professional way. Books such as Code Complete, The Pragmatic Programmer or Clean Code can teach you about how to program properly to produce quality code.

OK, after a lot of efforts, our program code compiles well and all the test cases are passed. So, it is ready to be deployed in (pre)production environments... However, after some use of the program, several anomalies use to arise in the form of unknown/unpredictable behaviors. Of course, these are our well-known "bugs". This book, guides the practitioner in the art of debugging code introducing techniques and tools used in the academia and the industry.

Finally, even when we think that we have smashed all the bugs in our programs, we have to deal with other kind of errors (e.g. in the form of hardware failures, such as power outages, hard disk failures etc.) That's the reason why we design fault-tolerant systems. However, I'll talk about them in other posts. In the meantime, I'll try to not make so many errors... But, you know... that's life!

P.S. How many errors are in this post?