Two more tales

The COBOL compiler mystery

A major computer manufacturer invited me to present my decision table methodology to their software developers. After the presentation a group asked if I would demonstrate how it worked by looking at a very specific problem. They explained that there was a persistent problem in their COBOL compiler. I agreed to try to solve the problem.

We spent a few days constructing decision tables from the language specification. While constructing one of the tables, two groups of programmers disagreed about how a particular part of the specification should be interpreted. Each group had a different understanding of the intent of the specification.

I mediated the lengthy discussion that ensued. It was obvious that this ambiguity was the source of their problem. We looked at the pros and cons of each interpretation and then voted on which one to adopt. Once this decision had been made, the group, who had had the counter-interpretation, went back to their offices and rewrote their code. The rebuilt compiler no longer had the problem. (This all happened a few years after the compiler had been released to customers.)

The Jims and their epiphanies

Two colleagues, both named Jim, and I were working on a new file storage mechanism for a mainframe computer. (Our goal was to pack and unpack data into strings of contiguous bits. The target was to gain at least a tenfold increase in data density without incurring a large penalty in access speed.) Neither Jim was interested in using decision tables. They estimated that the task could be accomplished in about two weeks.

While they coded their solution I drew the decision tables and prepared a test with which to test their code. About 10 days later they claimed that the code was ready to be tested. I tested their pro­gram using the test I'd prepared and it failed in many different ways. I showed them exactly where it was failing. They felt that they could take care of the problems in a couple of days. A week later the code was still failing a number of tests. At this point I shared the decision tables with them, explained how they worked, and we coded the solution from the decision tables. The resulting code was much smaller than their original code and worked correctly for all the test cases.

All three of us left the company within the next three months. One of the Jims repaired to California to work on flat-bed plotters; the other went to the NIH to work with lab-computers; and I went to Minnesota to work on machine-independent operating systems.

The California Jim called me late one evening about six months later. He had been wrestling with a particularly difficult problem. Out of frustration he decided to try a decision table. His experience convinced him that decision tables really worked. He became a decision tables devotee and has used them ever since.

The other Jim called me a few months after his namesake. He told me about the problem he had been having interfacing a lab instrument to a computer, and how he had solved his problem by us­ing a decision table. He too became a decision table devotee.

Neither of my friends, both very capable programmers, had liked the idea of using decision tables to solve programming problems. After the two incidents described above both started using decision tables in most of their work.

Video Presentation

I have prepared a YouTube presentation entitled 'A Disciplined Approach to Solving Problems' that walks through a theoretical problem space and then through a real problem space. This is available here. It is easy to follow and, should you care to view it, I urge you to persist and watch all four parts.