“To err is human, but you need a computer to really screw things up.”
Of course, some human programmed the computer, so we get the blame for the whole thing.
My latest lament is about my Canon MX860 inkjet printer. The printer is about six years old but still runs well, save for a recent spate of B200 errors. The non-descript error message directs the user to tech support instead of giving any clue to what the problem is. A thorough cleaning of the removable print head fixed the problem in my case, but the error notification and documentation is less of an issue than the real problem.
It seems the designers thought that the B200 error was so catastrophic that it should bring the multifunction printer to a grinding halt. It’s a feature, probably intended to keep you from making the problem any worse (although that does not seem to be the case). Unfortunately my wife ran into the error when trying to scan a document. This is, of course, a multifunction device, and the scanner was not the problem. The problem is that it was inaccessible because of the bug reporting feature. It took me a day to figure out the issue and to properly clean the print head.
This design problem is not unique; it seems to crop up in designs all over the place. Another recent mess was having to fix the climate control on our Ford Fusion Hybrid. The temperature controls were all messed up and a system reset—which also erased all the settings and address book—did not solve the issue. As I recall, changing a voice command setting fixed the problem, for some reason.
These kinds of problems will be compounded with the ever growing number of IoT (Internet of Things) devices cropping up, as well as the increasingly interconnected cars and work environments. It can lead to silly but annoying (and possibly dangerous) situations like not being able to drive a car because the tire pressure sensor indicates a flat.
Often these issues are related to corner cases in system design. Developers already are tasked with so many other issues, ranging from safety to security, that they overlook what may eventually be a common case problem. The IoT craze compounds the problem because the pieces to the puzzle can involve dozens of devices and applications, leading to some interesting race conditions or dependency problems.
Imagine an environment where a control app on a smartphone has a bug and through a change of communication links locks up an application on a particular device. All the devices in the chain use secure boot, keys, etc., and each is linked and dependent upon their neighbors in the chain so it cannot be broken. That’s a feature.
IoT interdependencies are going to make differentiation between features and bugs harder. This actually be something a developer will consider when their company controls the entire chain, but that will be less likely as time goes on. Often the IoT framework will be coming from a third party simply because the complexity of the entire system is too great for one company to handle.
So I encourage developers to add a little flexibility into their solutions, especially when it comes to error handling. Unfortunately, most devices these days lack a real power or reset button.