Two Wrongs Can Make a Right (and Are Difficult to Fix)
Code never lies. But it can contradict itself. Some contradictions lead to those "How can that possibly work?" moments.
Consider a function that returns a completion status. 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 inserts it.
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 symmetry is broken, as well as the code.
And this doesn't only happen in code: the problem also exists in specifications. 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