Can You Trust Your IBM i RPG Team to Provide Valuable Advice?

Avoid your IBM i crisis with ASNA!

Give us a call in the US at 800.289.2762 or in Spain at +34 902 365 787.

Visit us at asna.com or email us at info@asna.com.

You need reliable and solid input about your IBM i RPG application to make effective decisions about it. Unfortunately, those who know the most about the application can't always be counted on to provide you with the most critical, effective input.

An IBM i management-level decision maker needs lots of information about the business's RPG application before making any decisions. This usually means talking to the programming team that wrote, and currently maintains, the RPG application and talking to the team who will be charged with replacing it. But beware, neither team is well-equipped to give you the cold, hard truth.

Warning: Generalizations follow! Not all RPG and PC programmers are as described below. But many are.

RPG programmers

You need cold, objective, logical advice. Your RPG programmers may not be the best people to ask for that advice.

In most businesses running IBM i applications, RPG team leaders have been intimately involved with this RPG application for many years—often several decades. For many, your RPG application is quite literally their life's work. They are deeply invested in it and their strongly held opinions about it are often formed emotionally, not logically or rationally. The conundrum is that while these are the folks who know the most about your application, they are often not the best input source as to what you should know about that application. You need cold, logical, rational advice and they often think with their heart, not their head. Other factors may also be at play when you ask them for their input regarding the future of your business's RPG application. Consider the factors below:

  • Your questions will likely make them defensive. Most of these RPG applications are decades old. They were created by self-taught programmers with little formal computer science experience. This is nothing to be ashamed of. These RPG coders did amazing work and that these applications are in use decades later is a testament to that fact. However, as you start to probe and consider the future of their RPG application, it's only natural for that to inject uncertainty and doubt. Their defense mechanisms cloud their objective thinking.

  • You are challenging their comfort zone. It may also be that for many RPG team leaders it is easier to defer decisions than to make them. Many RPG programmers are deep into a decades-old comfort zone and the notion of disrupting that comfort zone isn't very appealing. Rather than be challenged many would rather ride out the last few active years of their career doing simple maintenance tasks that are well within their technical expertise.

  • PC programmers are threatening. It isn't true for all shops, but for many (many!) shops, it's likely that little peace and harmony exists between RPG programmers and PC programming teams. The thought of a bunch of busy-bee, egghead PC programmers (at least in the RPG coders' minds) looking over their shoulder asking, "why?, why?, why?" will not engage their willful cooperation in any application persistence initiative.

Your RPG programmers likely consider your RPG application to be their life's work.

For some, resistance is even more primitive. That RPG application is their legacy. They are proud of it and think it should live forever. These programmers aren't interested in helping with anything that borders on a complex, critical assessment of that application.

The RPG team may use the "If it ain't broke, don't fix it!" defense. To them, the app is in fine shape and they're likely to recommend budget dollars be spent elsewhere. The fallacy, of course, is that they are talking about today, not five years from now—when they are retired.

RPG team leaders that think this way are not nefarious nor are they selfish evildoers. It's a natural reaction to want to remain in your comfort zone. Motivations, fears, and desires drive everyone's decision-making at an almost subconscious level.

Through it all, there is one thing the RPG programmers will get right. The impetus behind most of their assessments will be that the business simply can't survive with its RPG application. On that core fact, they are correct.

All of this puts you in a challenging proposition. RPG programmer opinions are suspect and should be carefully considered, but on the other hand, these RPG team leaders know the most about an application that has little, if any, written documentation. They are the go-to resource when anything goes wrong or needs modification. No one else knows the application like they do. You can't avoid talking to them about the future of the application. However, when you do, consider your words and your approach very carefully.

PC programmers

The term "PC programmers" is a bit nebulous and we struggled to think of a better name for this team. For this white paper, we're using that term to define your non-RPG programming team—which usually means C# or Java programmers. These programmers create enterprise application with their PCs to run on servers. Don't read anything pejorative into us calling these programmers "PC programmers."

The opinions of PC programmers must also be solicited and carefully considered. Like RPG programmers, PC programmers also have an internal agenda and also may not be well equipped to provide the cold, logical, rational advice you need. Consider these factors:

  • PC teams are forever anxious to write something new. Most PC programmers like new things. New frameworks. New libraries. New languages. New tools. They want to use the cutting-edge features and components they just read about on Twitter or Reddit. They also get frustrated with the constraints legacy systems impose and they want to learn technologies that look good on their resume.

  • PC programmers don't know the IBM i very well. In almost every case, PC programmers don't know the difference between your organization's IBM i and its air conditioning unit. They don't know any of the IBM i's strengths, they don't appreciate the complexity and durability of the RPG application, and they may also think that the RPG programming team is a bunch of dinosaurs way past due for retirement.

  • PC teams are an over-optimistic bunch. Without solid knowledge of what the RPG application is doing or an appreciation for its complexity, a PC team will almost always insist that the app can be rewritten in six months. Any app. Of any size. And of any complexity level. Do not believe them. They can't do this. They aren't lying when they say this, they are woefully over-optimistic. They really believe it. But they are wrong!. See this article for more on the perils of The Big Rewrite.

Businesses the world over have wasted millions of dollars on The Big Rewrite Read about Florida's $77 million dollar software failure.

Despite all of this, the PC programming team also needs to be listened to and their input considered. They bring a different perspective and a different set of disciplines that help bring light to all angles of the challenge.

Do I need a haircut?

What is a decision maker to do? It's a challenging topic and we've got a few ideas for you. However, there isn't a magic answer. We've seen many real-world examples of the personas we've cited here many times. We know that they can be destructive forces that can cost an organization a lot of time and money. However, we also know that when guided correctly, the RPG and PC programming teams can be enormous assets as you chart your business's course.

Maybe Warren Buffet said it best: "Don't ask your barber whether you need a haircut."

Our next article provides a little insight that may help you guide and integrate your RPG and PC programming teams.

© 2021 ASNA. All rights reserved. v1.355