Imperfect Indicators

Home » Thoughts and Musings » Thomas M. Tuerke on Design »

design: /di·'zin/

n a deliberate plan for the creation or development of an object. vt: to create something according to plan.
good design: /'gud —/ the product of deliberate forethought and careful understanding of the purpose of a subject, resulting in a subject which significantly improves its utility, allowing it to integrate seamlessly and naturally into the role for which it is intended.
false synonyms: fashion, decor.

Table of Contents [show/hide]

Tue Dec 13, 2005 Link to this entry

Imperfect indicators are those which closely parallel a state you're trying to watch, but are themselves uncoupled from it. Being uncoupled from that state, of course, means that isn't always accurately representing that state.

A real-world imperfect indicator is looking at the ground to see if it's been raining: wet condition implies rain, dry condition implies no rain. The weakness of imperfect indicators may seem obvious in this example. It just takes a neighbor watering the lawn to give a false indication that it's been raining.

As silly as the example above may be, it's surprising how common imperfect indicators are in software, the subtle inaccuracies they bring about, and the sometimes convoluted measures that then have to be taken to work around the inaccuracies. So it's good to take some time to prevent them being designed into code.

Imperfect indicators usually are identified by succeeding some "if" syllogism, but failing the similar "if and only if " (often abbreviated iff) syllogism. For example: "if it is raining, then the ground will be wet." This sounds true. But let's look more closely: "if—and only if—it is raining, then the ground will be wet." Ah, clearly false, as the neighbor watering the lawn clearly indicates.

Sections: 4

RE: Imperfect Indicators

Tue Dec 13, 2005 Link to this entry

— Thomas M. Tuerke
If you've forgotten Logic 101, here's a refresher:
if p then q (or p implies q) But note that it is a fallacy to infer that q implies p: given "if p then q " you cannot be sure that "if q then p "
iff p then q goes that extra step: in this case p implies q and q implies p, so "iff p then q " means "if p then q and if q then p "

RE: Imperfect Indicators

Fri Mar 3, 2006 Link to this entry

— Thomas M. Tuerke
Here's a very remote example.
At one place, submission documents had a naming convention that usually incorporated a build name: Q134INI1, where 134 indicates the submission happened against build 134. Over time, the large number of contributors and builds resulted in a huge collection of submission documents, and it became necessary to categorize them.
Somebody on the project decided that the number of submissions made in one quarter (3 month period) was "about right" so the practice was to take each calendar quarter's submission and scurry them away into folders named "2004Q1" and "2005Q3" and so on. That's nice, but completely arbitrary. Other than resulting in a clump of files that was "about right," that really doesn't have much going for it. Developers—at least not these developers—don't think in terms of quarters. So when they're trying to look for submission document Q184FML4, they're at a loss. In what quarter did build 184 happen? Sure, there are tools where you can search for files on disk, or through the source repository, but these are slow (exceedingly slow if you're a remote site).
A more useful means of categorizing these would have been to group submission documents into "build decades": builds 100-109 into one folder, 110-119 in the next, and so on. This way, when somebody is looking for said Q184FML4, they know to go into the "Q180-189" folder and then scroll down. No need to search: an instant indexing method available without effort.

RE: Imperfect Indicators

Mon May 22, 2006 Link to this entry

— Thomas M. Tuerke
An example of an imperfect indicator: when, for whatever reason, a state variable is kept out of reach in an opaque implementation (say, as a protected or private member of a class.) Sometimes, a wrapper or associate object might try to maintain a parallel but fallible indication of that state.

RE: Imperfect Indicators

Wed Jul 5, 2006 Link to this entry

— Thomas M. Tuerke
Here's a concete example of an imperfect indicator.
A while back, I was investigating a piece of hardware for home automation. You may have seen these doo-dads at Radio Shack under the name Powerhouse, but the root technology is called X-10. In this case, I was testing a a programmable controller for turning on and off devices in a client's house.
Being programmable, that meant it came with software that you ran on your computer to teach the controller about the things it's controlling. You could also leave the software running and have your computer control the devices, turning them on or off with a few keystrokes.
This is where the imperfect indicators come in. You see, a light (for example) could be on or off. You can send the command to turn on, and the light would turn on. Send the command to turn off, and the light would be off. That's just fine... except the software wanted to create a status "dashboard", showing which devices had been turned on and which had been turned off. Since the X-10 units don't (well, didn't) tell you whether they're on or off, it was up to the software to remember each device's state. If it sent an On command, the software remembered that the device was on; when the Off command was sent, the software kept track of that, too.
Two problems should be obvious:
If you turn on the device locally (for example, use an X-10 light switch to turn on a light) the controller, and thus the software, would not be aware of this.
If you start the software while some lights are already on, it would have no way of knowing this fact, so the on/off indicators in the software wouldn't reflect reality.
In this case, the software created imperfect indicators—its own repertoire of device states—which weren't closely-enough coupled to the actual states to be reliable.
Imperfect indicators usually spawn awkward work-arounds in order to minimize the disparity between the two states... (and when some seemingly-crazy behavior is evident in something you use, consider that it might be a bandage over one of these.) For example, the software designers might have reasoned that they could have obviated the second item above by imposing the awkward imposition of forcing the real world to reflect the state of the software when it started up: that is, turning everything off whenever you launched the software. But that still doesn't solve problem 1...