RPG and Programming

One rule repeated in almost every discussion of programming is, “Don’t re-invent the wheel.”
The idea is, if someone has written a program, routine, or system to solve a particular programming or business problem, it is foolish to waste programmer time and other resources writing another routine to accomplish the same thing. With RPG now more capable of working in a mixed-programming language environment, the suggestion now often is, if a program in C solves a programming problem, it is better to call the C routine, by whatever means available, than to insist on writing it in RPG.
As a concept, I think it makes sense. At least superficially, it seems pointless to duplicate someone else’s effort. Since often you don’t know the identity of the person who wrote the original routine, I like to call the practice “Depending on the Kindness of Strangers”, after the famous line from Tennessee Williams’ play “A Streetcar named Desire”.

But when it comes down to the implementation of the practice, I sometimes think that depending on the kindness of strangers in programming is about as good an idea as it was for Blanche Dubois - in other words, not very good.

Is It Really Invented?
First of all, at what point do we say that the wheel has been invented? What if the wheel is not really finished, that it is not round? What if it is some kind of uneven-sided polygon? Or a perfect - octagon? Or an elegant oval? Should we be satisfied with our wheel if it does not really meets our needs, or meets them poorly? (Imagine an oval wheel. It might roll, but would you want to ride in a car with four oval wheels?) Where do we draw the line? If all we wanted was was a vehicle that moved people, we could have stopped with the Duryea brothers vehicle in 1893. Why do we keep re-inventing the wheel?

Who Says It’s an Invention?

For another thing, one person’s wheel is another person’s shiny new invention. Suppose there is, on your system, a 30 or 40 line RPGII subroutine designed to format separate city, state, and zip fields into one 40 byte string. If you think this routine should continue as your standard for this process, you will say that suggesting other ways to do it would simply be re-inventing the wheel. On the other hand, if you are an RPG guru promoting the use of RPGIV facilities to create a much shorter routine, the new way ought to be implemented. In other words, the change is not “re-inventing the wheel” if you are the one that wants the change.

Is It the Invention You Want?

Also, the fact that software exists that handles, for example, inventory control or warehousing, does not mean the the wheel has been invented for you. I worked for firms that bought packaged software in the above categories and then spent man-years of time modifying the software to try to fit their needs. In one case, the system, written for Unix, was intended to replace an AS/400 system; I understood that the software was very expensive, and it was made more expensive by the month as a number of programmers struggled to make it work. I remember thinking that the money they spent on the purchase and revamping of the software could have paid for an army of RPG contractors to upgrade the existing system.

The moral of the story being, if you do buy a software package, make sure it fits as closely as possible your actual needs. It is better if you can write your own software in a reasonable time frame. You can then include the functions, all the functions, and nothing but the functions you want.

Is it a Broken Wheel?

Another factor to consider is, what if the wheel is actually defective? At one job, we were getting errors in the running of a process. Upon investigation, I found the culprit to be a certain program that had been depended upon for years to carry out a key step in the process. And it was just plain wrong. The wheel was broken. Just because a program says it will perform a function doesn’t mean it will perform correctly.

For these reasons, I am very leery of depending upon programs that are not written by me or at least have source code I can readily consult.

Subprocedures

Much of the promise of RPG subprocedures is that you can bring commonly used processes into a service program or some other separate module and refer to it by a simple function call. Say the process is called “countitall”. You could say tot=countitall(amt1:amt2:amt3). You wouldn’t care how countitall did its work. “Don’t worry; it will be all right; you can depend upon the kindness of the strangers who wrote the routine.”

Now, you can’t be too picky. You have to depend upon the kindness of the RPGIV compiler writer. And even if your routine was open source (it was available for your inspection), if your only language of fluency is RPG, and the routine is written in C or C++, you are still trusting the programmer to do it right.

I can’t do much about the compiler writer, but I much prefer my own code to code that I cannot inspect easily. And if a program is built from separate modules, it is a substantial chore to track down the source of the modules or service programs. Perhaps that is one reason why I am underwhelmed by all the hype about service programs and subprograms.

All in all, I believe it is wise to try to avoid depending on the kindness of strangers.

This entry was posted on Wednesday, July 9th, 2008 at 11:26 pm and is filed under Personal, Programming, RPG, RPGIV. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.