Archive for March, 2009

Take It Personally

Monday, March 30th, 2009

Who is responsible for creating software that works? Where should the responsibility lie?
In large software corporations, programmers will occasionally lose sight of this. A Microsoft e-mail involving Bill Gates and Moviemaker is instructive here.
This kind of situation, of course, is probably not unique to Microsoft. But still, who should be the one in charge of software quality? In this case, someone a lot lower in the hierarchy than Bill should have caught the errors and corrected the problems. And I don’t mean the project leaders, either.
I submit that each and every programmer is responsible for software quality, and he or she should be aware that the software he writes should never just be “good enough”. The software he writes should work as it is expected to work, and certainly not crash when it is being used as it is supposed to be used. This is not to say that your software will be bug-free; that may not be possible to guarantee. The next bug in your program (and obviously, we are dealing with non-trivial programs here) probably just hasn’t been found yet. But programs should not crash and burn under the most simplistic of test conditions. (I’ll never forget the time I double-clicked on the WordPerfect icon on my Windows 3.1 desktop and got an “Illegal operation” error.)
Recently, I was making some revisions to my file/program cross-reference programs. It was a substantial change striking to the source of the data I used in my program. When this was done, whole chunks of my program were commented out, to be removed later entirely once the new code was tested. Errors started popping up all over the place. (Never forget that a “bug” is not some creepy-crawly that got caught in your code; it is an ERROR.) I was actually trying to get work done that more directly relates to my job- which is not to create utility programs. I was trying to get a project done with my utility as an aid, and if it wasn’t crashing the programs, it certainly wasn’t acting as it should.
But I was taking it personally; if I write a program, it is supposed to work as designed. My program may not do everything it might ultimately be able to do; but what it does, it should do right. If I right-click on a program name, it should bring up the source for it- look in the right place for it- not tell me it can’t find it or bring up the wrong one. When I click on a file name in a program and hit the appropriate function key, it should show me the file and field description or even the data; it must not lie to me and say the file is not there, and it certainly should not crash because I performed some subfile operation wrong.
What should be the first line of defense against errors, then? It should be the individual programmer. He should consider errors unacceptable. Bugs should not become “features”. He should be willing to beat on his code, test it by as many avenues as possible. Often it is best to forget you are the programmer and just USE the software as the individual user would. If you test it in “programmer” mode, you may tend to not test it in situations where the logic is more complicated and likely to fail; to save face with yourself, you might test it in “safe” areas under ideal conditions rather than push it to its limits.
Consider it a matter of pride. Beat on the program yourself. If errors are to be found, you be the one to find them, not the user. Consider it a matter of dishonor when a user finds an error. You may not be able to prevent users entirely from finding errors; but don’t let their finding errors be the accepted mode of software quality. Whether the tester be the user or some testing team, make their work as light as possible.
Don’t let “Bill Gates” find your errors. You find them.
Take it personally.

Programming and Thinking

Sunday, March 8th, 2009

I have read on more than a few occasions that it is important what programming language that you choose to write programs in, because it has a bearing on how you think about programming problems. An RPG programmer will likely approach a report program with an entirely different view than a C programmer. In this case, the RPG programmer would likely be able to take a more direct approach to the program than the C programmer, who would likely need to pay more attention to how to express the precise report layout. On the other hand, while compilers are written in C, I shudder to think of what a compiler written in RPG might look like. And can you imagine an RPG compiler written in RPG? Niklaus Wirth’s Oberon compiler was written in Oberon. Don’t ask me how.

This subject came to mind as I contemplated some of the indicator-laden code written for our system over the past 35 or so years- some original code, some heavily modified and added to over the years.

The code, of course, is hard to follow. It may have been easier to write. It’s easy to write code conditioned on one or two indicators; then a condition or two must be tested for, and all of a sudden you are slowly spun into a swirling maelstrom of competing indicators, repeating your original two as you go down the page and see how many permutations of the other three can be devised, how many of each permutation are used before the combination changes, with an occasional sixth or seventh indicator thrown in for good measure. And of course the output is conditioned on each of those permutations, with individual fields based on further combinations of those and others outside that group.

As I said, some of that code was written in the 70’s, before structured concepts began to be widely used, and certainly before they were applied to RPG. I learned how to do this even before concepts like IF-THEN-ELSE-END were even part of RPG. (See my 5/10/08 post “The Good(Indicators Part 2)”.) Evidently, not too many people read the same magazine articles I did, and even fewer implemented the concepts before IBM began to implement them in RPGIII for the System/38.

What is sad is that even after the concepts were made available, they were not well implemented in our shop. Maintenance of the old code was hard enough, but the more they modified the programs in the style they were written-whether RPGII or RPGIII- the harder they became to follow. And when RPGIV came out in the mid-90s, it was effectively ignored. I think I wrote the first RPGIV programs on our system in 2007.

When you are unwilling to implement new programming ideas, it makes the maintenance task even harder. If, when RPGIV came out, they had begun tweaking the code to make it easier to read, it would be easier to follow now; and sometimes relatively trivial tasks would not be attempted simply because the techniques that made them simple were ignored. By maintaining the old mindset, a lot of time that could have been used progressively was wasted.

A big example of this comes in the area of string handling and editing of numeric data. Of course, the handling of string data on a character-by-character basis has to be done in RPGII, RPGIII, and RPG400 by pushing them into arrays and manipulating them as individual array elements. Formatting of numeric values into, say, dollars and cents, must be done by means of edit codes and edit words, which are character patterns that define the look of a number.

An example: On a line of a subfile of a transaction history, the two numbers to be displayed could be dollar amounts (12345.67) or interest rates (123.4567). In generating the subfile, I found that you could not format the numbers in one of two different ways(using edit words), depending on whether it was to be dollars and cents or a percentage rate. This was unacceptable to the the screen format compiler; you had to pick one or the other, and the dollars and cents version was selected. This, of course, then has to be translated mentally by those who use the screen.

The solution, then, would be to output a value that could be expressed in two different ways. What I did a few years ago, before RPGIV was available, was to write the value to a temporary file (just as I would to a print file), then chain to that file and pull out the newly formatted value for use. To format a date, I would write a date as ‘03/08/09′ to a file, then access that 8-character string. Somewhat of a kludge, but it would work. There are no doubt other ways to do this in RPGII or RPGIII, but they are still likely to be kludges.

But in RPGIV, it becomes a piece of cake: Suppose you have a 7 digit numeric field NBR. You can then define a 10-character field FIELD and two edit words as constants: DOLLARS ‘ , 0. ‘ and PCT ‘ 0. ‘. You then say

IF (dollar value) EVAL FIELD=%editw(NBR:DOLLARS)




This FIELD is the value that then goes into the subfile. It was very easy to test, implement, and put into production. The users were very pleased.

Now, this solution that took me only a very short time could have been done a long time ago, but it wasn’t. The possible solutions, based on the way of thinking engendered by the old programming language (RPGII) made a simple correction a daunting task, and evidently it was felt it would take too long to implement.

Now, this was not intended necessarily to be self-congratulating. It was meant to show that not being willing to learn new and better things can have longlasting consequences. More to the point, being too deeply immersed in a certain programming linguistic style can cause one to avoid ideas that could be better both for you and for your users. In an environment like this, it may not be practical to choose between C and RPG; but while choosing new stuff (change) may not always be better, it CAN be.