To Err Is Human

Sometime in your programming life you will get a reminder that you are human – unless, of course your ego is such that you will never admit to error. One of those times happened to me a few weeks ago.

I had finished a substantial system a short time before, a system with only one screen program, but with a number of batch processes to update data, print reports and notification letters (converting them to PDFs) and email them to users to send out, at their discretion, to customers. I created four or five new files and used Aaron Bartell’s excellent RPGMAIL program to produce and send the letters. It was all original programming, very much out of my largely maintenance/upgrade routine at a longtime IBM Midrange employer.

I had developed a very possessive feeling about “my” code. I tested and retested my code heavily, so I had a great deal of confidence in my code, and I felt there would be little more than trivial revisions or corrections from then on.

So it bothered me very much that a user had submitted a trouble ticket telling me that he was seeing instances of dates being pre-filled onto my display screens. The user is supposed to put in the date he notifies a customer about the issue being dealt with by the letter; but the user was telling me that the dates were being pre-filled by the system, and that they were in fact usually old dates, before the letter was even generated.

THIS could not be. The program was not designed to pre-fill dates. So it was not happening. It must be user error; he must be putting in erroneous dates and forgetting about it. MY program was not pre-filling dates. I double-checked my screen program code, then (fortunately, not out loud or in print so anyone else would know) dismissed the issue as user error and went on to other projects that were really more important.

But time went on and the problem persisted. It was brought to my attention again. It finally dawned on me that this was happening too much, and the pattern was too persistent, for it to be user error. So I decided to dig a little deeper and look at the file update programs.

And I found the problem. When I was building history records, I read the history file itself first to prepare for further processing. Then, when appropriate, I wrote a new history record. What I forgot to do was initialize the record format before writing a new record, or at least make sure I explicitly filled every field in the format before writing it. I missed a few fields – and one of those was the date displayed in the screen. The date needed to be initialized to zero, but I was writing the date from a previous read of the customer I was working with, or even another user entirely. So I fixed it, tested it, and notified the user to keep an eye on it.

No matter how skilled you are in programming, you must realize (hopefully, without being forced to do so by an irate user) that you are going to make stupid mistakes. When I started learning to program back in the late 1970’s, I heard and read a number of stories about programmers with massive ego problems. Usually, the story ended with an example of a big problem created by the programmer who thought he was a genius. Supposedly you have to be smart to learn how to program, but often smart people must learn that they are not as smart as they think they are.

So I am glad that I was reminded so gently that it is a smart programmer who learns from his mistakes and realizes how stupid he really is.

4 Responses to “To Err Is Human”

  1. Buck Says:

    I was REALLY smart in 1978. Each year since then, I’ve become… hm… less smart. But my code has got smarter, so I’ll take that trade-off.

  2. David Smith Says:

    I will also add that programmers often find it difficult, if not impossible, to KEEP THINGS SIMPLE! How many times have we seen programs, Web “apps,” etc. that are so confusingly user UN-friendly that ONLY the programmer could use the application? I will answer that rhetorical question: many times! A glaring example of this problem is a help desk application such as Computer Associates’ Unicenter with its horrible ticketing system that ONLY on programmer can use. This system is so unfriendly and unintuitive that it’s useless for end-users. The bottom line: KEEP IT SIMPLE!! Keeping things simple takes work; making things difficult is easy.

  3. David Smith Says:

    I will also add, again, that programmers need to have a user-analyst involved because programmers (at least most) do not have the ability to think like the end-user and see the end-user’s experience/perspective of how the application will be used. So, use a user-analyst and programmers should stick to the programming!

  4. martin Says:

    Hi, been enjoying reading your articles
    I do not have an RPG background but about 2 months ago was ‘made’ the as/400 sys admin in my company, sort of an unpaid promotion, because I was a programmer (PC’s, JavaScript, MS SQL, VB). I either had to learn RPG or tell them I couldn’t do the job. It’s an ERP system, all of it including customisations is in RPG III so for now that’s my starting place. I re-wrote a customised screen with subfiles to understand that and started looking at the core ERP code. My opinion of RPG: I like it. The curve balls and gotcha’s are no worse than web development languages. It’s satisfying plumbing away in SEU. The global scope is a bit of a worry then the indicators. I have seen.. massive monoliths of highly strange subroutines 10k+ lines long. I don’t believe many programmers could cope with this. Luckily I thrive on this sort of stuff but this is beyond what I ever have seen before. to ‘know’ these programs well.. years of intimacy! some are dated 1982. I now know I will be changed if I have to change some of these.. but the process has already begun as I enter the world of the sales order management screen. I aim to make some money with RPG yet

Leave a Reply