Designing for the degenerate case
In mathematics, a degenerate form is one that cannot be perturbed in some way without being rendered a member of a larger, more complex class. For example, a circle is a degenerate ellipse- change the constant multiplier of one of the terms and you push the form out of the class of circles into the larger class of ellipses.
Next time you're solving a problem, ask yourself: am I solving for a degenerate form? And, if the answer is yes, is that important? Let me give an example where the answer to both questions was "yes". I was tasked once with supporting some motion code which was intended to align a circuit board on a conveyor belt under a camera.
The code as written worked fine in the lab, but in the field, customers began to complain of erratic and unpredictable behavior- boards which would be incorrectly positioned at the start of inspection, pushed off the end of the conveyor, etc. It turns out that the code had originally been written to the degenerate case of a PCB that had no slots or notches and was less than 300mm long- even though the system was specified to handle ANY board of a length up to 450mm in length. The result was that it was relatively easy for a slot (or even a hole for a component lead in boards coming through before soldering) to allow enough light through to fail to activate the accurate positioning sensor, resulting in a misaligned board. Longer boards caused a problem too- they would be (only occasionally) detected as fault conditions because they would trip more than one sensor at once. Once I rewrote the code with the mental model of trying to align a picture frame with non-parallel leading and trailing edges (basically, the broadest possible class of objects that could come through the machine), a huge number of field issues resolved immediately.
Perhaps the most serious of these degenerate cases is the "normal" human. I have a number of "abnormalities" (if you will; I hope I don't offend anyone with my terminology but it's important, I feel, to consider denotation rather than connotation and to realize that "abnormal" is, in fact, a term with no qualitative meaning) of capability which have rendered my life, if not worse, at least harder than necessary. The most significant one is my colorblindness. I'm a deuteranope* - I have a great deal of trouble with red-yellow-green colors. I have a great deal of trouble with bicolor LED indicators- the colors of yellow, orange, red, green, and amber used in cheap indicator LEDs are all basically identical to me, differing only in intensity. The result is that I can get relative information from them (changes in state) but I can't get absolute information from them (is the light red or green?). If the encoded information is VERY important (for instance, stop/go signals at an intersection), and color is the ONLY way it is presented, or the only absolute way in which it is presented (for instance, some areas have stoplights that are horizontal, and green can be on the left or the right depending on the orientation of the intersection), the result can be disastrous. At best, it's an annoyance to roughly 10% of the population who lack "normal" color vision.**
The best way to avoid designing degenerate case flaws into a system is to explicitly write down what your expected use cases are. Get other people to look at them, and to look for holes in them. It's okay to discard their feedback, and it's not always important to expand your design to break free of a degenerate case (sometimes it's just too expensive to support every use case, and sometimes other restrictions rule out the need for supporting some use cases)(no need to encode the speedometer in a car such that a blind user can interpret it, for example), but you should consider them just the same. Fixing a design after the fact is far more expensive than doing it right the first time.
* I think I'm a deuteranope, anyway, based on discussions with a very smart coworker (who happens to be deuteranomolous). Most online colorblindness tests will only provide a better diagnosis than "yes, you're colorblind" if you enter SOMETHING in the field next to the Ishihara plate image, as the shape you see is what determines what type of colorblindness you have. I can't see ANYTHING in most of them, but "nothing" isn't an option. Ironically, these pages were probably designed by someone with normal color vision who completely failed to consider my case.
** So how to solve this problem? Use two LEDs instead of one with two colors, so the information is position encoded as well as color encoded. Use a blink code. Use colors which will be discernible to the largest number of potential users (relatively few people have a kind of colorblindness that causes them to confuse blue with any other color). Use significant differences in intensity to encode information.
Next time you're solving a problem, ask yourself: am I solving for a degenerate form? And, if the answer is yes, is that important? Let me give an example where the answer to both questions was "yes". I was tasked once with supporting some motion code which was intended to align a circuit board on a conveyor belt under a camera.
The code as written worked fine in the lab, but in the field, customers began to complain of erratic and unpredictable behavior- boards which would be incorrectly positioned at the start of inspection, pushed off the end of the conveyor, etc. It turns out that the code had originally been written to the degenerate case of a PCB that had no slots or notches and was less than 300mm long- even though the system was specified to handle ANY board of a length up to 450mm in length. The result was that it was relatively easy for a slot (or even a hole for a component lead in boards coming through before soldering) to allow enough light through to fail to activate the accurate positioning sensor, resulting in a misaligned board. Longer boards caused a problem too- they would be (only occasionally) detected as fault conditions because they would trip more than one sensor at once. Once I rewrote the code with the mental model of trying to align a picture frame with non-parallel leading and trailing edges (basically, the broadest possible class of objects that could come through the machine), a huge number of field issues resolved immediately.
Perhaps the most serious of these degenerate cases is the "normal" human. I have a number of "abnormalities" (if you will; I hope I don't offend anyone with my terminology but it's important, I feel, to consider denotation rather than connotation and to realize that "abnormal" is, in fact, a term with no qualitative meaning) of capability which have rendered my life, if not worse, at least harder than necessary. The most significant one is my colorblindness. I'm a deuteranope* - I have a great deal of trouble with red-yellow-green colors. I have a great deal of trouble with bicolor LED indicators- the colors of yellow, orange, red, green, and amber used in cheap indicator LEDs are all basically identical to me, differing only in intensity. The result is that I can get relative information from them (changes in state) but I can't get absolute information from them (is the light red or green?). If the encoded information is VERY important (for instance, stop/go signals at an intersection), and color is the ONLY way it is presented, or the only absolute way in which it is presented (for instance, some areas have stoplights that are horizontal, and green can be on the left or the right depending on the orientation of the intersection), the result can be disastrous. At best, it's an annoyance to roughly 10% of the population who lack "normal" color vision.**
The best way to avoid designing degenerate case flaws into a system is to explicitly write down what your expected use cases are. Get other people to look at them, and to look for holes in them. It's okay to discard their feedback, and it's not always important to expand your design to break free of a degenerate case (sometimes it's just too expensive to support every use case, and sometimes other restrictions rule out the need for supporting some use cases)(no need to encode the speedometer in a car such that a blind user can interpret it, for example), but you should consider them just the same. Fixing a design after the fact is far more expensive than doing it right the first time.
* I think I'm a deuteranope, anyway, based on discussions with a very smart coworker (who happens to be deuteranomolous). Most online colorblindness tests will only provide a better diagnosis than "yes, you're colorblind" if you enter SOMETHING in the field next to the Ishihara plate image, as the shape you see is what determines what type of colorblindness you have. I can't see ANYTHING in most of them, but "nothing" isn't an option. Ironically, these pages were probably designed by someone with normal color vision who completely failed to consider my case.
** So how to solve this problem? Use two LEDs instead of one with two colors, so the information is position encoded as well as color encoded. Use a blink code. Use colors which will be discernible to the largest number of potential users (relatively few people have a kind of colorblindness that causes them to confuse blue with any other color). Use significant differences in intensity to encode information.
You're such a degenerate.
ReplyDelete