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

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
Code never lies. But it can contradict itself. Some contradictions lead to those "How can that possibly work?" moments.
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.
+
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 <code>TimeToLive</code> instead of <code>TimeToDie</code>, 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.
Or consider an application that stores state as an XML document. Imagine that one of the nodes in incorrectly written as <code>TimeToLive</code> instead of <code>TimeToDie</code>, 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.
-
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.
+
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.
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.

Revision as of 16:38, 31 January 2009

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

Personal tools