Problem Solving

The solutions to complex problems are seldom robust. What exactly do I mean by that? Simply that the solutions are incomplete; there are no planned actions for many of the situations that may arise. Some errors are simply that – errors. Most errors are errors of omission. One source of unanticipated errors is a difference in the interpretation of the requirements and another is an inconsistency in the implementation of the solution. To solve complex problems, methodical methods for exhaustively enumerating all the possible situations that may arise, are needed.

The problem space, i. e. the combination of every possible alternative for every variable that describes a possible or impossible situation with respect to the problem, needs to be defined. All erro­neous and impossible situations must be identified and each must be handled as explicitly as any other situation. A seemingly ridiculous goal since a very large number of situations may be identi­fied. Fortunately, decision table can be shown to represent such problem spaces succinctly. Decision tables are useful for solving all kinds of problems, not just those related to computer programming.

The origins of the decision table

Some form of decision table was first tried in the 1950s. But like flow-charts, they were simply a crutch that enabled early programmers to get some idea of how they were going to program the solu­tion to a problem. Early decision tables were neither complete nor robust.

In the early 1970s IBM started using DECTAT, a decision table translator for PL/1 and COBOL. I couldn’t find anything in the tool that enforced completeness. None of the tables, that I looked at in IBM's docu­mentation, was complete. (The reference manual is available from Google Books – AF37765).

In 1964 the late Tom Rozwadowski and I set out to solve a very complex problem. We had worked together as a team for 5 years; first at LEO Computers and then at Control Data Corporation (CDC). The task was to write drivers for some very special devices that our customer wanted to connect to a computer system that we had never seen. Although we were employed by the company that made the computer it was impossible to get any documentation about how to interface hardware to the system. In frustration we decided to analyze how all the interfaces, for external devices connected to the computer system, were programmed.

A few years earlier Tom and I had made a proposal to a government for the implementation of a na­tional population register. We had used tables to analyze the requirements. We realized that similar tables, with a few extensions, would make it possible to analyze the device drivers in the new com­puter's operating system. By the time the hardware was delivered our drivers were ready. We in­stalled our drivers, connected all the devices to the computer system, and tested the devices. All the devices operated correctly and we were able to control the devices using our installed drivers. The methodology proved to be very robust and we both continued using it from that time forward.

Neither of us was able to convince any of our colleagues to use our methods. We read everything we could find about decision tables but found that none of the methods were robust. We had planned to formalize the whole concept together but this wasn’t to be (Tom and his family died in a tragic acci­dent in October 1970). How I completed this task will be revealed later.