Investing in Ruby or RPG…Can I just talk to Chuck?

Well I’m not Charles Schwab, so the answer is unfortunately no, you can’t talk to Chuck!

While I’m admittedly no expert on stock investments, I do have a few thoughts when it comes to assessing future viability of programming languages.  But before I digress, a short personal bio is in order for you to gain some understanding on the perspective and questions I’m about to convey in this post.

My first programming opportunity

My first employer out of college had literally dozens of AS/400’s (yes, I am using the correct nomenclature – this was back in the early 2000’s) with my role starting as a systems operator.  Eventually this led to an RPG programmer.  After a few years I realized I often was given projects on the fringes that the other RPG programmers didn’t want:  emailing from RPG, web development from RPG, EDI from RPG and XML web services from RPG.  You’ll notice a trend of “from RPG” in that last sentence.  We were an RPG shop and that was the language used for 99% of all projects within my dept.  A few years into employment as an RPG programmer I discovered open source and the Java programming language.  I was impressed by how much business value I was able to deliver with minimal effort.  With Java I was able to do things like generate Excel spreadsheets, create graphical charts, “talk” to the desktop, post to Twitter, and generate QR codes.  All of this would have taken months in RPG – if I could even accomplish them at all.  The ability to accomplish business objectives faster can have a number of positive side effects, but of primary importance is simply remaining competitive.  Learning Java also led me to pick-up Android development – a whole other world which we won’t be entering in this article.

The point I am trying to drive home is that I wasn’t able to accomplish my goals with a single language – namely, RPG.  In my earlier days I used to have a saying: “There’s very little you can’t do with RPG, so use RPG”!  What my naivety didn’t take into account was that missed deadlines mean lost revenue, and considering revenue is necessary for businesses to survive I realized my approach to technology recommendation needed to change.  I should also note I am very aware of the various options of doing modern development in RPG.  I attend five to eight conferences a year and have insight into the RPG modernization options (i.e. web application frameworks written in and for RPG).  Many of these tools are built with excellence.  The issue comes when you need to do something outside of the box in which they’ve been developed.  There is a time in which community-supplied tooling becomes important.  RPG does not have an active open source community in comparison to other languages.  The “other languages” are what my competitors are using and thus are able to generally move forward faster.  The good news is we have some of the leading languages now supported on IBM i: Ruby, Node.js, PHP, and Java.

Now that I’ve primed the pump it’s time to get back to the topic of investment.  Below I’ve listed a number of questions every shop should consider when needing to make choices relevant to new technology adoption.  While every business is different, many questions (like the talent pool availability of resources with specific programming language experience) are relevant to all.

Is the community surrounding my language-of-choice worth investing in?

One oddity of programming languages is their ability to foster certain personalities.  For example, many RPG programmers were groomed away from business backgrounds (i.e. accounting, shipping, and inventory control departments) and had an intense focus on providing business value versus desiring to learn and adopt new technology.  This is one reason why I’m a big fan of Ruby.  The language is great but the community is even greater.  Like I mentioned in my earlier Ruby Community post, I’ve concluded there is no concession that can be made for an active and progressive community.  A vibrant technology community translates into a vibrant business.

What is the cost/benefit of staying where I’m at?

I don’t consider myself to be a huge risk-taker.  Instead, after years of reviewing technology, I like to view myself as an adventurous pragmatist.  What does this look like in practice?  It means when a new technology comes out I will give it a test drive, reviewing both positive and negative online commentary to gain a balanced view of whether it’s good for certain customers or scenarios.  I actually thoroughly enjoy doing this and will sometimes forego relaxation because it’s less “pain” to pursue said technology vs. trying to relax and pretend I don’t need (want?) to do research.  So what I’m trying to say is, “Every shop that develops custom software needs to have somebody with some semblance of being an adventurous pragmatist” – otherwise you just end up not finding better ways of doing things.  It’s through this practice of evaluation you can learn whether the current way of doing things is the most cost effective for the business.  I’ve come to the conclusion that developing web applications can simply be done significantly faster with frameworks like RubyOnRails.

This type of research is an investment which pays great dividends by being able to make informed decisions.  Not all shops have this type of personality within their team.  Sometimes it’s necessary to engage an outside resource to inject a jump-start on what to consider and pursue.  Consider engaging the Litmis Team for purposes such as this.  Contact them at team@litmis.com.

What is the cost/benefit of moving forward?

As mentioned above, learning new technologies is essential to success.  The next step is adopting them.  This should never be a flippant practice as adopted technologies (those implemented in production) will typically be with a business for a long time.  Thoughtful consideration should be made on the front to determine long-term viability.  This is where the review of a community can give valuable perspective concerning the future promise of a technology.  Even after you choose a new technology like Ruby there will be additional decisions within that ecosystem.

What is the future of the technology I am currently using (i.e. RPG or COBOL)?

Some say “RPG is dead”.  I used to debate that but found declaring absolutes (i.e. dead or not dead) is silly because the world of technology is much more gray than black and white.  A better question to ask is whether the technology on my IBM i is currently meeting my needs.  A good way to know this is to look at how you do web development.  Do you have a separate web development team that does NOT deploy to IBM i?  That’s a very telling reality.  At some point someone determined IBM i + RPG wasn’t adequate to do web development.

What is the future of the technology I am adopting (i.e. Ruby/Node.js)?

Amazon deploys to production every 12 seconds.  How do they do that?  With automated processes.  How are processes automated?  With tools.  Who creates tools?  A vibrant community.  While deploying to production every 12 seconds is overkill for most shops, deploying multiple times a day should be something shops are at least capable of.  Why?  So users and customers don’t have to wait.

This is why comparing languages is only part of the picture.  It is instead necessary to see the entire loop of how software development, deployment, and delivery occurs.  For example, unit testing is a first class citizen in the Rails web framework – built-in from the beginning because they realized the only way to deploy frequently with reliability was if an entire code base could be automatically tested and confirmed to work correctly.  Even further than unit testing are tools like Capybara that actually load up the browser and interactively, and in automated fashion, click through your web application.  See it to believe it.

A few years ago I was lead developer on a RubyOnRails project to develop an online school from start to finish – in 9 months.  The features included student registration, course catalogs, tuition payments, grade books, report cards, student/teacher collaboration, live classrooms and more.  It was probably one of the most fun and intense projects I’ve ever worked on.  Most importantly, it taught me that delivering value in a timely fashion reigns supreme.  By using the tooling available from the Ruby community we were able to push changes out multiple times a day with very little disruption.  The process was as follows:

• Make a code change.
• Run unit tests to confirm nothing was broken by change.
• Commit changes to the private GitHub repository.
• Click a button to deploy.

From there the automated deploy process would use Capistrano to ssh into the machine, download the changes from the Git repository, put up a “please hold while we apply updates” page to temporarily stop traffic, run any ActiveRecord migrations, then switch a symbolic link from the previous directory to the newly downloaded directory, and then remove the temporary page to allow traffic to continue.  The scheduled “downtime” usually ranged from 15 seconds to 1 minute.

It is because of experiences like that that I could no longer ignore non-RPG based technology solutions.

How do I maximize my existing investment?

I especially wanted to get to this point because sometimes shops get so excited about new technology that they throw the baby out with the bath water.   By that I mean many times it’s a bad idea to throw away all your RPG code and start everything from scratch.  It is better to take inventory of what your RPG code accomplishes today and learn how to repurpose it during a time of transition.  This is where the xmlservice Gem comes into play as it allows simple and easy interaction with existing IBM i resources, including RPG programs.  This is a big deal because it allows incremental and partial migration to new technology, like Ruby and Rails.

If you haven’t heard, we (the KrengelTech Litmis Team) have partnered with IBM to maintain the xmlservice Ruby Gem.  You can visit the public Bitbucket Git repo here.

How far do I migrate away from RPG?  Do I just do a thin layer on the front-end?

There are many levels of adoption one could make of Ruby and Rails.  For example, you could make it so that Rails’ ActiveRecord (the layer used to communicate with DB2 from Ruby) was never used to interact directly with DB2 tables and instead all DB access was done through SQL stored procedures that invoked RPG programs.  I’ve seen this approach in a number of shops.  It’s usually because there’s not enough trust of the web developers to use the database in direct fashion.  While it can be fine to go this route, I would consider it a stepping stone because with this approach there’s an additional layer of code that needs to be maintained.  That time could be better spent training the web developers how to use the database.

Another recommendation I hear for new development (emphasis on new and not transitory), is to do all web stuff in the new language (i.e. Ruby) and keep all the business logic in RPG.  I admittedly don’t understand this approach because it introduces a very complicated infrastructure, and complication leads to slower feature development and release frequency.  Languages like Ruby are very capable of business logic.  And even better, they have excellent unit testing frameworks so you can make sure future changes don’t ruin existing business logic.

Do I keep my web portion on the IBM i?  YES!

Another oddity I often see is people running web workloads on Windows (and sometimes Linux) instead of on IBM i.  If your web application is in .NET then you have little choice but to run it on Windows.  But if it is written in an IBM i supported language then it can significantly lessen complication to run it in its own subsystem on IBM i – a machine made for this type of workload.  With that said, I do empathise with some on this front because it can be scary to put your machine on the web when you aren’t a security expert.  To this point we intend to document some web security best practices in future articles.  Again, you’ve made investment in IBM i and DB2 for i, so it’s best to capitalize on that investment as much as possible.

So now you have some approaches to consider when looking at your upcoming technology investments.  We’d love to hear your thoughts or further questions you might have.  Shoot an email to team@litmis.com or simply comment on this post!

---

Questions?

Still want to talk to Chuck? ,Go ahead and give him a call.  His number is 866-855-9102!