Frequently, programming is associated with the arts. But I have to disagree. While I believe the phrase "programming is an art" is true, the way some people apply programming skills is akin to the way some tradespeople apply construction skills.

When a new feature is needed or a program needs to be changed, some programmers do an immediate "quick and dirty" repair and call it a day, while other programmers take a little more time and build something that will last into the future.

As an analogy, suppose you have a crack in your wall that needs to be repaired. One repairperson may fix it using spackle, drywall, compound tape, a wet sponge, and paint. Another repairperson may cover up the problem by simply slapping a coat of paint over the crack. Certainly, in both cases, you don't see the crack when the work is complete. In one case, you have the illusion of spending less money, but in the end, you always end up going back and paying for it (and then some) later.

Depending on the severity of the crack, which type of job would you prefer to have done? For example, suppose the crack in the wall is caused by an original imperfection in the workmanship that is now being aggravated every time severe rain hits your area. The crack frequently appears to be static (not growing) so you choose to simply paint over it. Weeks or months go by, and the crack doesn't return and you forget about it. But the next time a heavy rain hits, the crack grows a little more, resurfacing through the paint. You've got the same old problem again.

I find it terrifying that so many programmers are simply slapping a coat of paint over their programming problems. Whether it's a habit learned from years of their employers telling them to do it quickly and "just make it work" or it's the fact that they are simply poor programmers (obviously, readers of this column are great programmers!), the result is the same. Slapping a coat of paint on everything every time is going to come back to haunt you. These quick fixes that work only in a specific situation or fix only a specific problem are similar to painting over a crack in the wall.

The engineer Rube Goldberg had a wonderful cartoon series in which he often depicted solving the simplest of problems using the most complex solutions he could dream up. Think of the old Mouse Trap board game, and you'll know what I mean.

Today, a "Rube Goldberg solution" is often used as a derogatory remark to someone who advocates a solution that is over-engineered or too crazy to implement. For example, let's say we need to solve this problem: Add one day to today's date, giving tomorrow's date.

A Rube Goldberg-style solution might be this:

1. Prompt the user for today's date.
2. Prompt the user for how many days he wants to add to today's date.
3. Ask the user to go to a calendar hanging on the wall and find today's date.
4. Ask the user to count on his fingers the number of days he wants to add.
5. Ask the user to go to the calendar hanging on the wall and then, using his fingers, count that many days forward on the calendar and remember that date.
6. Ask the user to enter the new date.
7. Use that new date in the rest of the program.

A non-Rube Goldberg solution might be to use the ADDDUR opcode.

Doing the Right Thing

I think programmers frequently succumb to pressures from above. They do what they can to satisfy their customers, which, in an iSeries shop, typically means the users.

Programmers rush to get the job done quickly, perhaps introducing errors and implementing code that only fixes a specific issue without regard for the bigger picture.

Here are a few examples that illustrate some of the characteristics of quick fixes:

Hard-Coding Values in RPG Code

Hard-coding values has long been a problem with RPG in general. It wasn't until the 1990s that the RPG III language spec was changed to support named constants. This change was carried over into RPG IV and is a powerful solution to hard-coding so-called magic numbers or other literal values.

Hard-coding Production or Test-Library Names in CL

Hard-coding in CL is a bit more convenient, but your own discipline should stifle this habit. Simply declaring a CL variable to contain the hard-coded value (also known as a literal) can solve this problem quickly.

Using *CURLIB Instead of the Library List

Using *CURLIB is an interesting problem. I see people using it with the assumption that the current library is effectively static. I also see it when programmers really meant to use *LIBL or no qualifier at all. Instead, they "hard-code" *CURLIB in the CL. This can lead to all kinds of issues. For example, it effectively restricts future library list changes when additional data is placed on the library list in front of the library normally identified with *CURLIB. Those files will not be detected and used if they also exist in the *CURLIB.

Using a GOTO

Using a GOTO... Need I say more? OK, I will. CL is perhaps the only language that requires a GOTO to complete the job. Look at the MONMSG command for the quintessential example. IBM is working on improvements to CL, and V5R3 offers some major improvements. But 90% of all programmers I spoke with said, "That's cool, but who cares?" when asked about the CL enhancements.

Take Your Time and Do It Right

"Just fix it" is fine for a time-critical situation where you need it done now no matter what. But then you need to go back and resolve the problem with a permanent, widespread, proper solution.

I've seen situations where programmers have hurriedly done a poor job with the application in the first place and then spent countless days putting out fires when the users ran each piece of the application. Sure, one or two things occasionally work correctly, but sometimes developers end up "fixing" poorly working code with poorly written fixes.

In general, RPG programmers write working code because the language encourages it and their history is writing and using code that doesn't blow up. In other languages, something the equivalent of the MOVE opcode might work sometimes and not work other times (due to data issues). But in RPG, we just don't have this type of problem.

Doing it right the first time may not always be possible. But doing it right is the right thing to do, even if it means redoing your existing code.

I received a notable response recently from a programmer after I pointed out that his use of *CURLIB in the overrides for an application would cause issues with this multi-company application and that he needed to remove *CURLIB or change it to *LIBL. He responded, "I spent more than 30 hours going in by hand and entering those things. Don't you think we could just change the requirements rather than spend countless hours undoing what I've done, and then we could just fix things if problems come up?" My response was, "If problems come up? You mean when problems come up."

Needless to say, I began to understand why some people get fired.

Bob Cozzi is a programmer/consultant, writer/author, and software developer. His popular RPG xTools add-on subprocedure library for RPG IV is fast becoming a standard with RPG developers. His book The Modern RPG Language has been the most widely used RPG programming book for more than a decade. He, along with others, speaks at and produces the highly popular RPG World conference for RPG programmers.