ASNA White Paper: The Decade of Crisis for the IBM i and RPG - part 6
Striving for IBM i Programming Team Harmony
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.
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."
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.
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."
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
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.
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
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 Who Do You Trust, 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#.
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.
Don't underestimate your need for input