Recently I started reading Computer Programming Fundamentals. Although this book was written half a century ago, I still found a lot of insights which is still up-to-date until now. While I faced the exercises in the first chapter, I decided to provide some answers here on my blog publicly.

This time I would like to deal with problem 1-2:

Would any of these devices or the devices mentioned in the chapter make a really major change in the performance of the cash register? Try to think of a device which would make a major change in performance.

To put this into context, in the chapter Leeds and Weinberg introduce a cash register, rather simplistic 50 years ago, but still a part of the computer history. The problem 1-2 then asks the reader to imagine additional devices which makes the cash register less error prone. Having served as a cashier about ten years ago, I think I have something to contribute on that.

The cash register in the book is a simplistic version. You can add prices, and calculate a total as a cashier. When I was starting to work as a cashier in a local supermarket back in 1995, we had an advanced cash register at that time. The one I was operating had the ability to add prices, and show the totals, but beyond that I could enter up to 16 different material groups, like food and non-food categories. Beyond that we had things like groceries which had special numbers – price look-ups, PLUs.

Another chapter in the book is on errors and handling errors. Since humans introduce errors to the cash process, we had several mechanisms to correct these errors. We had the ability to make correction entries, cancel the last entry made into the cash register, or with a special key cancel the whole receipt.

Beyond that we had the ability to enter cash payments, check payments, and special purpose-based checks which were called “restaurant checks”, from which you could only buy food items. The cashier had the responsibility at that time in that store to check the proper usage of restaurant checks as you couldn’t buy for example cigarettes using these.

Some years later new cash registers were introduced. Previously all items in the store were labeled with price tags. If a price tag was missing, as the glue did not stick enough on it, we had to ask for prices. The new cash registers supported electronic scanning of bar codes with a look-up in a backend system.

Up to that point in time I was able to register items in a very fast manner. Several hours of duty had taught me the skill to type very fast prices using the keyboard. Sometimes I had finished the cashing process way before the customer had filled their bags. I was quite ambitious at it as a teenager.

now, the scanners introduced a different system to the process. First of all the crew had to scan every item. Everything was stored in a computer, and every bar code had to be put up in the backend system, so that the cash register would notice any item. Therefore we no longer had the need to ask for missing prices – as the backend system would provide them.

At least that was the selling argument for that new system.

Several weeks into the new system, I noticed some patterns with these “improvements”. The cash registering process slowed me down – sometimes tremendously. Scanning the bar code was sometimes hard, sometimes bar codes from magazines were crinkled. This was a huge drawback, but on the other hand now customers were able to proceed as fast as I was proceeding their items.

But there was another factor, the human factor which the crew forgot. Sometimes when new products arrived, just one or two of the ten items were created in the backend system. This led to eight items unable to pass the cash register automatically. Their were even some departments well known to forget about this process quite often. But I digress.

Now, the human factor played a role there. This is a lesson which also Leeds and Weinberg mention in their chapter on error handling for computers – in a book written in 1961. The human factor in computing leads to so many errors. My own experience more than ten years ago reflects this as well.

Now, what has this to do with testing? Everything! If we want to test a product well, we have to understand the human factor in computing and how real humans deal with real applications. What are the errors they make? What are the factors and itches they circumvent or find ways to avoid? This knowledge is a path to better software in the long run, if we are able to find solutions as a team of business analysts, testers, and programmers.

Seeing this lesson to clear in a book written 50 years ago still makes me a bit worried. Haven’t we learned a thing in the past 50 years about that? It seems not so much, but there are promising implementations – unfortunately they seem to be exceptional to me.