Introduction

---

What Is a Programmer Illness?

Repeatedly I see the same mistakes being made during software development. These errors hide behind slightly different masks, but at their heart, many of them are the same. I have made many of these mistakes myself, not realizing that I was repeating the same errors until well after they had been made . Even one of these mistakes can have far-reaching consequences for a software development project; making them over and over is guaranteed to cause loss of time or money.

Many projects I have worked on started out with a goal to avoid past problems. Unfortunately, the projects often fell into the familiar programming traps with all the corresponding complications associated with them. One of the major problem areas projects fall into is having to perform considerable optimization work toward the end of the project. Knowing that this was a major problem, we established a mandate to optimize this new project from the very start. Optimizations were made early and were considered to be of primary importance. There was also an emphasis on early completion of features using whatever means necessary.

However, these methods led to several of the classic mistakes made by programmers. By focusing on optimization alone, the code was made difficult to understand and hard to modify. As the project went on, changes became increasingly difficult to make, and fixes to existing code took longer. This led to cutting of features and simplification of the project’s scope. A considerable amount of extra work was also accrued due to the distrust of the performance of externally generated code, such as the C++ Standard Template Library, and higher-level language features. This further reduced the amount of new features that could be implemented, and made standard features more onerous to implement. Topping this off were the other common mistakes not related to the goal of optimization, such as cut-and-paste coding used to implement features quickly in the short term. All this meant a considerable amount of time, and hence money, spent on a small feature set.

So, was this reduction in scope worth the performance gained from this approach? Unfortunately, the desired performance improvements were not realized, resulting in the hiring of a consultant to optimize the application near the end of development. Despite the intentions and efforts of the developers, loss of time and difficulties in development were not offset by the desired performance goals. Although the project was completed, more could have been achieved in the same time, or the project could have been finished earlier. Even a successful project leaves a lot of room for improvement, and there is hope that many of the team members took away lessons from the failures in the project as well as the successes.

Over time, seeing these errors has led to the metaphor of an illness to describe these commonly repeated mistakes. This metaphor serves several purposes, most important as an aid to remembering the importance of each of these mistakes. Comparing programmer mistakes to a more common problem of human illness also allows each mistake to be discussed in a structured manner that aids in reference and recall. Programmer illnesses, just as regular human disease, can also be communicable. A new programmer is very likely to pick up these mistakes from his mentor. A programmer working on code filled with the little bugs will be less careful and might, through lack of caring or out of necessity, introduce similar bugs. These problems must be prevented or caught and cured early to reduce their impact on your project.

On a slightly less serious note, some of the terminology already in use is reminiscent of the fancy terminology used by doctors. For example, Premature Optimization and NIH Syndrome sound like some strange disease or mental condition. In a way, these actually do describe a mental condition present in many programmers. To counteract this problem, you must be disciplined in your approach to design and coding. This importance of discipline is evident in the recent success of Extreme Programming and other agile methodologies. These new methodologies suggest an approach that requires fewer but more disciplined programmers to accomplish the same tasks that a larger group of average programmers would take the same amount of time to do. In addition, nobody wants to catch a bug, be it in code or in our blood.

---