Let’s look at a trilogy of developer habits of we which should be afraid. Be very afraid.

It’s October, which means Halloween is coming up. I’ve always been a fan of scary movies, which will play nonstop in theaters and on television all month long. So why not have a little fun with a look at some frightful habits that many RPG developers continue to practice?

While this theme is in jest, these are things that we as RPG developers need to stop doing. All three are considered time-savers, but at what cost? It’s time we invest in the quality of our product instead of cranking out more of the same old stuff that has gotten us by for years.

Code Copying

How do you make a dreadfully evil program even worse? Duplicate it dozens of times. Want to be a mad scientist? Take parts from several programs and splice them together to create your own version of Frankenstein’s monster! This is a sure-fire way to spread evil throughout your enterprise. Muahahaha!

We as developers copy code for many reasons. Sometimes, we’re lazy (or as I like to call it, efficient). More often, we’re under the gun and need to get things done yesterday. Regardless of the reason, it’s often very easy to look around for code that’s “close enough” and reuse it. But many times, this is the worst thing that you could do. I have worked on many projects in which had to ask a developer, “Why are you doing these calculations here?” or “Why are you using these RPG or DDS keywords?” All too often, the answer is, “I don’t know. I copied it from another program, and it seemed to work.” This also means that our code, and skills, never advance beyond the level used in the original code base of our application. That code base can often be decades old.

Don’t get me wrong. I’m not saying you should write every program from scratch. I am a firm believer in having templates for things I do often in application development. But these templates are not complete applications that I will hack around to try to conform to my current requirements. They are boilerplate code that I not only use, but periodically update as the language and my skills progress.

Even worse than duplicating entire programs is copying subroutines from one program to another. Subroutines are always globally scoped, meaning variables and files used within are almost always defined outside of the subroutine. Copying subroutines between programs is a recipe for trouble. Even if you manage to handle all the global dependencies, you run the risk of variable-name collision with other parts of the program. Not to mention, you have now duplicated a business rule and increased your required maintenance should said rule change.

Any time you consider copying a routine from another program, you should go ahead and move the code into a reusable subprocedure. The code you are copying is obviously useful outside of the original program, so why not make it easier to reuse in the future?

Arcane Programming

You are the Merlin of the MIS department. All other developers cower at your knowledge of obscure programming tricks and use of the logic cycle! Others do not understand your genius and the programming magic you wield within your applications.

As crafty and knowledgeable as you are, remember one thing. You are not immortal. One day, someone else will need to maintain your code. Chances are, your replacement will have no idea why you are multiplying a numeric field that contains a date by 10000.01. Don’t use “magic” like this in your code. Be explicit about what is happening. Never assume the next person will have seen that method before.

Use free-format RPG. Yes, you read that right. I fully understand that you can do anything in fixed-format that can be done in free-format. Take the time to learn and use free-format. Remember, you are an all-powerful RPG wizard. Surely, you can learn a new syntax. However, it is very likely that your successor will not be versed in fixed-format programming syntax.

Never write another production program using the logic cycle. Yes, I know the cycle is magical and will use its arcane powers to read through files and break out to perform logic under defined conditions. Apart from a quick one-off utility, don’t use it. Think back to when you had to learn all the intricacies of using the cycle. It likely took years for you to fully understand everything about the cycle. Even now, you may be confused by an obscure behavior that you haven’t dealt with in years. Why put someone else through all that work? Just explicitly write code for looping and I/O and save the next developer some headaches.

Lack of Documentation

Witches and warlocks keep their powerful knowledge and spells in spell books. They guard these with their lives as their knowledge makes them powerful. Don’t horde knowledge. Share! Many developers keep copious notes on everything in notebooks or digitally on their computers. While this is extremely useful to that developer, it does nothing to help others.

Take the time to document your code. Start with meaningful comments in your code. When maintaining someone else’s code, a comment that says “multiply price by quantity” isn’t really useful. I’m a developer, I understand math. Tell me why we are multiplying these variables. Is this to determine a PO line item cost? Is it calculating raw material costs to determine profitability? Those are the things that I need to know. Use comments to give future developers context and guidance.

Take those pages of notes and find a way to share them. My preferred method is to use a wiki to allow all developers to document applications as they create and maintain them. Wikis are easy to set up and easy to use. They make sharing and searching information simple.

Wrapping Up

No, I don’t mean making a mummy. All three areas discussed this month are contributors to a concept that should scare your employer. It’s called technical debt. Any time we take a shortcut instead of doing things properly, we create technical debt that must eventually be paid. We are saving time now at the cost of time later. That cost can be increased maintenance time, application downtime, or other costs. Many times, we cut corners because we are on a tight deadline. I understand and have done it myself, but whenever possible, take the time to do things properly. Keep the future in mind. Explain to stakeholders the unseen costs of over-aggressive deadlines and the benefits of building a proper foundation for the future. After all, it is the company’s future you are trying to improve.