Scary RPG Developer Habits

RPG
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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.

Brian May

Brian May, an IBM Power Systems Champion and Solutions Architect for Profound Logic Software, devotes the majority of his time to assisting customers with their modernization efforts. He frequently writes and speaks on topics related to RPG, JavaScript, and IBM i Modernization. Brian recently contributed his time and expertise to the new IBM i Modernization Redbook.

 

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  •  

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: