Unplanned Design Behaviors

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. Both completeness and consistency is not possible. So, what usually happens 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 delicious before cooking it. Especially if you have never eaten the cake before. Or that a program will run correctly or will not crash completely. If you are designing an airplane or a Mars Rover you can simulate the behavior of the system on a computer but the simulation has to be calibrated correctly. I think it is impossible to prove that a system will behave according to design specifications completely because the designer is dealing with instructions that have to be done in a certain order. He has to process the instructions one by one to see what the behavior of the system is. A mathematician does not have to do this when proving a theorem. For instance, the statement Bob is mortal can be proved by the two premises: Bob is a person. All people are mortal. The two premises do not have to be in any specific order to make the premise true--they just have to be true themselves.