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

From WikiContent

Revision as of 14:14, 1 February 2009 by Allankelly (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 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.

When two faults in the code create one visible fault the methodical approach to fixing faults itself breaks down. The developer gets a fault report, finds a fault, fixes the fault and retests. However the fault reoccurs – because a second fault is at work. So the first fix is removed, the code inspected until the second fault is found and a fix applied for that. But the first fault has returned so the second fix is inconclusive and rolled back. The process repeats but now the developer has dismissed two possible fixes and is looking to make a third that will never work.

The interplay between two code faults that appear as one visible fault not only make it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on.

This doesn't only happen in code: the problem also exists in write requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description.

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.

There is no simple advice to give on how to address multiple faults. Awareness of the possibility, a clear head and a willingness to consider possibilities is needed.

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