In January 2004, the NASA Mars Rover froze when it had too many open files in its flash memory. This is an example of an Unplanned Design Behavior (UDB). UDBs are not intentional. I like the UDB term because it does not denote a deliberate error. Since mankind’s knowledge is imperfect there are bound to be UDBs.
Why do UDBs specifically happen? It usually happens when the mental design does not match the actual design of the designer. Call this Type 1 UDB. In software programming Type 1 UDB is called a bug. The more complex the program is the more bugs the program will have. Here I define complexity of a program as the number of conditional statements the program has. Conditional statements are If…Then…Else statements.
Type 2 UDB is where someone is following a plan and misses an instruction or misinterprets an instruction. For example, a cook following a recipe may leave out a step or by accident misread a cooking instruction. Or a killer puts on gloves so not to leave any fingerprints on a gun but does not have them on when loading bullets in the gun. In law enforcement leaving fingerprints behind is called evidence.
Type 3 UDB is where the design is either incomplete or inconsistent. According to Kurt Gödel’s “Incompleteness Theorem”, both completeness and consistency is not possible. So, what usually happens is the design is not complete or not as complete as it should be. Choosing incompleteness over inconsistency is not a bad choice. A designer has to choose one or the other, and I would rather settle with an incomplete design rather than an inconsistent (read: illogical) design. Since the design is incomplete the final product will not be able to deal with events outside its parameters.
How does a designer prevent UDBs? You cannot completely get rid of all UDBs. You can only minimize the number of them and try to make the system robust enough so it does not crash or go completely out-of-control. You cannot really prove the system won’t have UDBs. Try proving a cake will be …