Two Wrongs Can Make a Right (and Are Difficult to Fix)

From WikiContent

Revision as of 16:47, 2 December 2008 by Kevlin (Talk | contribs)
Jump to: navigation, search

Code never lies. But it can contradict itself. Some contradictions lead to those "How can that possibly work?" moments.

Consider a function that returns an error code. Imagine that it returns false when it should return true. Now imagine the calling function neglects to check the return value. Everything works fine until one day someone notices the missing check and adds it in.

Or consider an application that stores state as an XML document. Imagine that one of the nodes in incorrectly written as TimeToLive instead of TimeToDie, as the documentation says it should. Everything appears fine while the writer code and the reader code both contain the same error. But fix one, or add a new application reading the same document, and the sympathy is broken, as well as the code.

It is not only at the code level this can happen: the problem also exists at the specification level. And it can spread, virally, from one place to another. An error in the code compensates for an error in the specification.

It can spread to people too: users learn that when the application says Left it means Right, so they adjust their behaviour accordingly. They even pass it on to new users: "Remember when that applications says click the left button it really means the button on the right." Fix the bug and suddenly the users need retraining.

Single wrongs can be easy to spot and easy to fix. It is the problems that need multiple changes that are harder to resolve. In part it is because easy problems are so easily fixed that people tend to fix them relatively quickly and store up the more difficult problems for a late date.

By Allan Kelly

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools