IBM i Legacy Modernization and the RPG Programmer

There has always been a lot of talk about "Modernization" in the IBM i community.  

With all the new technologies in the world, some becoming available to the IBM i, there's no shortage of subject matter.

Most of this legacy modernization in the IBM i world is directed at RPG programmers, as it always has been.

As an overused example, years ago we were told if we don't learn Java we would be flipping burgers.  

A few years after that we were pushed to use EGL.

Now we're told that we need to learn PHP, Perl, Ruby, Node.js or some other new language that has been (or will be) "ported" to the IBM i.

In the coming years, what will be next?  What will it be that will "replace" RPG, only to end up not replacing RPG?

The Reactions

With each of these new technologies we get a range of reaction from our community.  

Some take the "You must do this or you will fail!" route.  

Others suggest you can keep your current RPG applications, but any and all new development should be done with this new latest and greatest technology.

Finally, some see that these new technologies can be a great addition to your programming arsenal and can be used if and when appropriate.  (This is the camp I fit in for the most part.)

So I have to ask, have we reached the point where RPG is no longer useful, or that we've done all we can do with it?  I don't believe this to be the case at all.

What is "Modern"?

Before we can get into what Modernization means, we should probably define it.

Yep, there's the problem.  Modern is in the eye of the beholder.

Modern to an RPG/III programmer could be free-format RPG.  

Modern could be being able to convert your spooled files to PDF and emailing them.

Modern could be replacing all of your copied and pasted code with ILE subprocedures.

But when an RPG programmer looks at the latest craze in development, do they think "modern" or "unnecessary for the most part"?  After all, they're working on the IBM i.  A machine that can do it all.

Most RPG programmers create and maintain applications to get the job done.  This normally means  applications that crunch numbers (AP, AR, Inventory, etc), perform reporting and keep businesses running.   Not glorious by any means, but very necessary.

Interfacing an inventory application with Twitter or a Blog is the last thing on most application programmer's minds.  

So "what is modern" is a hard question to answer depending on your point of view.  

This is probably why the use of the term "Modernization" is popular... there's no definitive answer to what "modern" is.  We can just label anything (except RPG it seems) as modern.

Why Target RPG Programmers?

It seems that the modernization message is mostly targeted at RPG programmers.  But saying this targeting is being done deliberately would be unfair.  

The fact is that RPG programmers just happen to make up the vast majority of developers on the IBM i.  Because of that, industry leaders, writers and pundits, by default, have an audience of mostly RPG programmers.

Do we really believe that all of these technologies are being ported to the IBM i so that RPG programmers will be forced to drop RPG and use them?  

No!  In fact, it's quite the opposite.  I feel IBM is pushing new technologies to draw a new crowd of developers to the hardware using something they are comfortable with as "bait".

Think of it this way.  If Microsoft ported RPG to PCs, do you think VB, C# or .Net programmers would argue among themselves saying "you have to modernize and start using RPG!"  

Of course not.  To quote Violet Crawley, "That's preposterous!"  (But, it would be pretty cool!)

So why then are RPG programmers being targeted for these new technologies instead of those working on other hardware platforms?  

Could it be the leaders and pundits in our world are just sharing their ideas with their standard audience base with whom they are most comfortable?

Reach Out!

I challenge the leaders and pundits in our industry to this:

Instead of trying to convert or shame the RPG programmer into using the latest and greatest technology that they focus your energies on those on other platforms!  

Step out of your comfort zone!

Extend your audience base to those outside the IBM i world and try to win them over!  

Sell the IBM i as the "do it all system" it is instead of trying to convert RPG programmers to the language of the day.

Converting RPG programmers to use the flavor of the month won't make IBM any more sales to grow our community.

But getting programmers from other platforms to switch to the IBM i will.

When Product Support Becomes Education

I've been an Independent Software Vendor (ISV) for over 20 years now providing IT solutions for the IBM i community (known previously as the AS/400, iSeries, System i, etc).  

As with any product or solution, support is one of the biggest selling points, and to me, one of the most important offerings from an ISV.  That's why we always strive to give the absolute best support possible.  Especially nights, weekends and holidays (when most IT professionals are doing upgrades and enhancements).

But when does support for your product stop being support, and start to become support for the hardware, the OS, or even fall into the category of "education"?  

For example, a customer just installed new hardware and calls support because email isn't working.  The email client they are using is your software which they transferred from another machine.  

The support call ends up being a 2 hour crash course educating your customer or client on some basic topics such as how mail routers, DNS servers and  TCPIP work, and how to set them up properly.  Most likely these things were set up on the old hardware by someone else, and not set up on the new hardware.   

Is this type of support expected?  Should it be billable?  If so, do you just refuse to help if they don't want to be billed?  

The reason I pose this question is over the past 20 years I've personally dealt with thousands of customers all over the world.  Within that group there is also varying degrees of education and technical know-how.

On one end of the spectrum there are those that take a piece of software, download it, install it and get it working.  I rarely hear from them (except for enhancements requests, which we love to get!)

On the other end of the spectrum there are those that need assistance creating a job log, adding a library to a library list, importing SSL Certificate Authorities and everything in between.

There is a line where product support becomes "education" and probably should be a billable event.

I would be curious to hear from other successful ISVs who include support with the cost of their product on how you handle similar situations.

I also would be curious to hear what customers expect from ISVs in the same situation.