Robust Design: Patch-It Principle

The software patch is a much maligned technique for keeping systems robust because many users perceive that the majority of these patches as merely fixes of feature bugs that the developers should have taken care of before shipping the software. While there are many examples where this sentiment has a strong ring of truth to it, the patch-it principle is a critical approach to maintaining robust systems so that they can continue to operate within an acceptable range of behavior despite the huge variability that the real world throws at them. This post focuses on the many other reasons (rather than sloppy and curtailed design, build, and test) for patching a system – all of which share the same basis:

The software patch is currently the primary approach for a system to manifest modified behaviors in light of additional information about the environment it needs to operate within.

The basis for this statement stems from what I have referred to as the omniscient knowledge syndrome, which is the assumption that designers should identify and resolve all relevant issues facing a system at design time. This is a necessary assumption because contemporary embedded systems are not capable of sufficient learning that allows them to determine an appropriate course of action to handle previously unspecified environmental conditions.

Common examples of patching are to add new capabilities to a system; to implement countermeasures to malicious attack attempts; and to implement special case processing to support interoperability across a wider range of hardware configurations, such as new combinations of video cards, system boards, and versions of operating systems.

New capabilities are added to systems experimentally and in response to how the market reacts to those experimental features. Patching enables developers to competitively distribute successful experiments to their existing base of systems without requiring their user base to buy new devices with each new feature.

A robust system should be able to counter malicious attacks, such as viruses and hacks. A perfect static defense against malicious attacks is impossible, or at least it has so far been impossible for the entire history of mankind. Attacks and countermeasures are based on responding to what the other side is doing. Patching helps mitigate device obsolescence that would otherwise ensue when malicious entities successfully compromise those systems.

The rate of evolution in the electronics market is too rapid for any developer to completely accommodate in any single project. The constant flow of new chips, boards, algorithms, communication protocols, and new ways of using devices mean that some mechanism, in this case patching, is needed to allow older devices to integrate with newer devices.

In essence, the patch-it principle is a “poor man’s” approach to allow systems to learn how to behave in a given condition. The designer is the part of the embedded system that is able to learn how the world is changing and develop appropriate responses for those changes. Until embedded systems are able to recognize context within their environment, identify trends, and become expert predictors, designers will have to rely on the patch-it principle to keep their products relevant as the world keeps changing.

To make following this series easier (especially as multiple series overlap each other), I am including the index below to previous posts. I encourage you to read all of the posts for the robust design series; maybe they will inspire you to share your observations. I would love to be able to consolidate different perspectives and lessons learned with regards to robust design practices here. I suspect there are some valuable lessons to be gleaned from comparing such stories. If you would like to participate in a guest post, please contact me.

Previous post in the Robust Design series:

2010, April 12:   Robust Design: Sandbox Principle - Playing Nicely

2010, April 5:     Robust Design: Sandbox Principle

2010, March 29: Robust Design: Fault Tolerance

2010, March 22: Robust Design: Ambiguity and Uncertainty

2010, March 15: Robust Design: Best Guesses

2010, February 10: Robust Design : Good, Fast, Cheap – pick two

2010, February   4: Robust Design