ASNA White Papers
In-depth anaylsis, examination, and observations about ASNA products and the IBM i eco system.
*Any decision you make about the future of your IBM i's RPG application requires the willful cooperation and help of both your RPG and PC programming teams. While you may never be able to fully integrate those teams, you can at least lay the groundwork for them to get along.*
We discussed your RPG and PC programming teams in Can You Trust Your RPG Programming Team. In that article we discussed the challenge of getting reliable and objective advice from them. In this article we take a look at some of the issues you’ll likely encounter as you discuss migrating your RPG applications with these teams.
The term "PC programmers" is a bit nebulous and we struggled to think of 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 applications with their PCs to run on servers. Don't read anything pejorative into us calling these programmers "PC programmers."
As a manager, you are surely very good at leading and motivating teams. We don’t mean to hand-wave away your experience and knowledge, rather this article seeks to remind you about some of the issues and angles you’ll likely encounter as you engage your programming teams in crafting a plan about the future of your critical RPG applications.
You have at least two development teams!
ASNA has done *many* IBM i RPG to C# migrations. Our nearly universal experience with enterprise RPG/PC programming teams is that they are two separate nations who speak two completely different languages. They are the IBM RPG nationals and the Microsoft C# nationals. A successful migration requires that these two teams understand and respect each other.
In our experience, the two nations are generally willing to communicate with each other but are not capable of doing so without an interpreter. Programming tools, language constructs, best practices, and myriad other issues conspire to make the gulf of communication between the two teams broad and deep.
Sadly, we’ve also learned that it is very challenging to make the two teams work together. Both teams have a substantial fear:
RPG team members fear they will need to learn PC programming or Web programming (or both). They are quite happy in their RPG comfort zone and don’t like the idea of rocking that boat.
PC team members fear they will need to learn RPG and IBM i operations. Like the RPG team, these team members are also quite happy within their comfort zone.
PC programming teams are often not accidentally unfamiliar with RPG. They've avoided it because it's not like their languages and most PC programmers perceive RPG to be an obsolete programming language. Some PC programmers will drive you crazy incessantly asking you "why?" "Why does RPG have indicators?" "Why are there asterisks everywhere?" "Why are field names always so short."
Beyond substantial technical gulfs and ingrained fears, we’ve also learned firsthand that:
Recalcitrant team members can dramatically impede an RPG application transformation. This is a critical point. Naysayers, with little appreciation for the big picture, are very destructive.
RPG and PC programming teams are often at odds with each other. For some shops this tension gurgles under the surface but for many it’s abundantly obvious. Like the naysayer, this friction is also very destructive.
Understanding programming team differences
It’s usually very challenging to achieve the ideal goal of fully integrating your RPG and PC programming teams. However, it’s important to do what you can to motivate them to respect each other and acknowledge each others’ contributions.
If your shop is the rare shop where the RPG and PC programming teams get along, congratulations! You've done a great job building your team.
One of the reasons your RPG and PC programming teams may be distanced is that in the past they’ve not had much need for each other. Another is that the two teams do very unrelated tasks-or at least work on very different parts of a project. There are also substantial technical differences between the RPG and PC programming teams. For example, you’ll likely encounter frustrations about:
Database access. By now many RPG programmers are using SQL, but they didn’t for many years while creating your RPG application. It’s likely most of the database access in your RPG application uses RPG record-level-access model (ie, RPG operation codes such as CHAIN, READ, READP, etc). Your RPG programmers intrinsically understand RPG’s record-level access model. PC programmers will almost universally not know or understand record-level access and have a better knowledge about SQL.
Web programming. In most cases, PC programmers are usually more directly involved with the Web and networking parts of your application and are therefore usually very familiar with Web programming. RPG programmers, spending most of their time with back-end RPG, tend not to know much about Web programming.
Community knowledge . RPG programmers have a wealth of knowledge, in their aging, gray heads, about how your mission-critical RPG application works and runs the business. PC programmer tend to work on the outer edges of that core application. They probably have little or no knowledge of how your RPG application works-or even why it is so important.
Developer operations. “DevOps” has emerged over the last three or four years to be critically important to PC developers. ( This video explains DevOps in just a few minutes). DevOps encompasses tasks such source control, application testing, integration testing, and application deployment. PC programmers will generally have some DevOps knowledge. RPG programmers may be familiar with source control, but are probably not as familiar with the full scope of DevOps as PC programmers.
Plan for negative reactions
As you discuss migrating your RPG application with your RPG and PC programming teams, plan for negative reactions from both.
The RPG team will likely be critical of anything that is suggested to replace your existing RPG application. It’s been their sole domain for decades and as far as they’re concern it works just fine.
The PC team will likely be critical of any replacement for your existing RPG application that doesn’t meet their ideal mental model of a replacement. As we said in this article, the PC team wants to use the latest tools and frameworks and aren’t focused on what the reality is of transforming millions of lines of RPG and CL to C#.
Don't underestimate your need for input
If not now, soon you will need to make critical decisions about your IBM i RPG applications. To do so, you'll need to have many critical and coherent discussions with your technical teams. Start laying the groundwork now for these conversations to be successful.