Recently I spent two weeks in Berkeley CA helping a client upgrade one of their control systems. I wasn’t involved in creating the original system, but I do have experience with the software. We reverse engineered and re-created the system. Testing went well until the fateful day we hit the wall.
The task is simple enough. The operator makes a selection, which sets a boolean value TRUE. The control computer detects the FALSE-to-TRUE transition, and sets a local variable to TRUE. Six seconds later, the operator’s value gets set to FALSE. The value in the control computer remains TRUE until other events occur that set the variable to FALSE.
This was the map I used until things didn’t work. The communication between the two computers wasn’t happening like it did with the original system. The original communication protocol worked synchronously. The new communication protocol works asynchronously. This didn’t matter for most actions, but did create problems with this particular code section. And while we could bend, fold, and mutilate everything on the operator’s computer, we couldn’t make any changes on the control computer. To make matters more interesting, the interface logic occasionally worked. So my map was sometimes correct, and sometimes wrong!
After a day of testing, re-coding, and testing again, we finally resolved the issue so the interface reliably worked. The actual code changes were simple. We spent the majority of the day deciding if the map was correct and the territory wrong, or the territory was correct and the map needed changing.
Maps make it easier for us to work with the real world (whatever that may be). Some detailed information gets removed, but if the structure is similar to the territory, the map is useful. The problem is deciding when and how to change maps.