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

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(New page: Code never lies but it can contradict itself. Some contraditions lead to those "How can that possibly work?" moment. ((Need to give an example)) This leads to the most difficult bugs to...)
Line 1: Line 1:
-
Code never lies but it can contradict itself. Some contraditions lead to those "How can that possibly work?" moment.
+
Code never lies but it can contradict itself. Some contradictions lead to those "How can that possibly work?" moment.
-
((Need to give an example))
+
Consider a function that returns an error code, imaging it erroneously returns false when it should return true, now imagine the calling function neglects to check the error code. Everything works fine until one day someone notices the missing check and adds it in.
-
This leads to the most difficult bugs to find and fix.
+
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). Everything is fine while the writer code and reader code both contain the same error, but fix one, or add a new application reading the same document, and the status quo is lost.
 +
 
 +
It is not only at the code level this can happen, the problem exists at the specification level. And it can spread between one level and 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, and they pass it on to new users: “Remember when that applications says click the left button it really means the right.” Fix the bug and suddenly the users need retraining.
 +
 
 +
Single wrongs are easy to spot and easy to fix. It is the problems which needs multiple changes that are difficult 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.

Revision as of 18:22, 29 November 2008

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

Consider a function that returns an error code, imaging it erroneously returns false when it should return true, now imagine the calling function neglects to check the error code. 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). Everything is fine while the writer code and reader code both contain the same error, but fix one, or add a new application reading the same document, and the status quo is lost.

It is not only at the code level this can happen, the problem exists at the specification level. And it can spread between one level and 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, and they pass it on to new users: “Remember when that applications says click the left button it really means the right.” Fix the bug and suddenly the users need retraining.

Single wrongs are easy to spot and easy to fix. It is the problems which needs multiple changes that are difficult 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.

Personal tools