I was discussing the benefits of RDi with a colleague this morning (I’m a bit of a Rational Developer fanboy) because he is trying to justify the huge annual cost of the tool with The Management: nearly $1000 per year per person! A price tag that is #bloodypreposterous. But, I will rant about that in another blog.
Anyhoo, my esteemed colleague asked me to send him a quick write up of some of the benefits. As an ardent fan of plagiarism, I turned to the interwebsuperhighway and discovered this excellent article, which is sadly marked for deletion in January. Yikes!
So here it is, re-posted before IBM can hide this wonderful source of old information:
A very common question is “Why should I abandon my current green screen tools that I am so proficient with and spend money and time learning a new environment?”
If you continue to read below you will get an IBMer’s perspective.
But you don’t have to take my word for it. Here are recent web articles and blogs from industry pundits (non-IBMers) that deal with the same issue.
A hard dollars and sense ROI calculation for IBM’s RDi – Charlie Guarino
How much is too Much for RDi – Jon Paris
More on RDi’s value equation – Susan Gantner
And here is an article from a regular programmer who used to love SEU on why he feels more productive with RDi
In the past I may have answered something like “PDM and SEU are old and Rational Developer for i is a modern tool for RPG and COBOL development.” With the exception of a few leading edge IBM i developers, this answer generally doesn’t go over very well (much the same way that I’ve learned “Because I said so” doesn’t work that well with my kids). Over the past year I’ve transitioned to starting all RDi demos with two slides: What is RDi and Why use RDi? I’ll explain the “Why RDi” here.
The short answer to why RDi can be summarized as:
If you’re happy with short answers, and want to take my word for it, you can stop reading now.
And finally here is an explanation of why RDi will save you money in a matter of weeks or months.
I believe improved developer productivity with RDi comes from the following areas: modern development features, integrated tools, tools to help understand programs, and customizations.
Improving developer productivity is the number one reason why both developers and IT managers should consider switching to RDi. Earlier I mentioned that simply saying “RDi is modern tooling” doesn’t work, which is true if that’s all you say. But RDi is a modern development tool for RPG, COBOL, CL, and DDS and those modern development features do improve productivity. PDM and SEU were designed over 20 years ago. Over those 20 years there have been major advances in the area of application development tools. It still completely baffles my mind that SEU does not have an undo feature!
Here are some of those “modern features” that lead to improved productivity (a complete list would take way too long and is beyond the scope of this document):
There are many tasks a developer needs to do to develop software: search, edit source code, compile, and debug are just a few. These are not done in isolation, you may search to find a specific source member, then edit it. After editing you compile, fix any errors in the editor, and then may debug it. RDi integrates these tasks so developers can easily flow from one to the other. Here are some examples:
Now that the basic search, edit, compile, debug cycle is covered in the RSE we’ve started to branch out into other tools that can help developers understand the structure of their programs. At one end of the spectrum there is the “show block nesting” editor feature that draws lines in the editor margin to match up the beginning and ending of code blocks.
There is also the outline view discussed above which can help understand the definitions and structure of the source member currently being edited. At the other end of the spectrum is the application diagram which can:
And of course, the application diagram is integrated with the editor so you can create a diagram from the contents of the editor, and quickly jump to definitions and calls in the editor by double clicking on entries in the application diagram.
RDi was designed to be customized. This includes customizations for specific development projects and personal customizations. Some examples of project customizations include:
Ultimately, customizations for both projects and personal preferences can make development more efficient.
Rational Developer for i is but one of many application development tools based on Eclipse. Others include:
Very few, if any, IBM i shops have only RPG / COBOL development projects. Most also have some type of Web, client/server, or application integration (SOA / services) development projects as well. Many of the solutions for these use Eclipse based tools. Take Web development for example:
If other teams in the organization are using Eclipse based tools, then using Eclipse based tools (Rational Developer for i) for RPG / COBOL development allows organizations to standardize on a common development tools platform. This opens up future avenues for implementing common processes and tools (testing, requirements gathering, change management) across all development projects regardless of programming language and runtime platform.
Improving developer skills is closely tied to the above idea of a common development platform. Developers can move to Rational Developer for i and continue working on the same development projects. In addition to the above benefits, this also increases the developer’s skills: they are learning to use Eclipse based development tools. This provides a strong foundation for these developers to work on other Web, Java, or Web service projects in the future because these projects will also likely use Eclipse based tools. So the future learning curve is lowered; developers still need to learn the new technologies, but they don’t have to learn a brand new development tool from scratch.
Using Rational Developer for i as your IBM i development environment can also help attract, and retain, new employees. The colleges that I know teach RPG programming do so using Rational Developer for i (which the students prefer over PDM and SEU). Showing these students a green screen development environment on the first day of work is not going to go over so well.
The ADTS tools were stabilized as of V6R1. This means that no new function has gone in to them for a couple of releases. In the mean time, the compilers have been adding tons of features to COBOL, CL, SQL and RPG. In particular RPG has added free-form declarations and there are myriads of other enhancements that SEU’s syntax checker will not recognize. RDi is getting all of the investment dollars and is getting large improvements like code coverage analysis for all compiled languages and dynamic outline view for RPG. It is clear that staying on the green screen tools will mean falling behind.
I don’t ever recall presenting or demoing RDi and having someone say that they just aren’t interested. Normally developers and managers alike are excited about the features and possibilities that RDi offers. However, it often comes down to the learning curve. Developers go back to their desks, get caught up in the day to day things that come up and never get the time to try, or become proficient in, using RDi.
RDi is a new development tool for SEU / PDM users, and there is a learning curve to become proficient in any new tool. Based on some case studies we did with WDSC (but also apply to RDi), the expected learning curve is around 3 weeks. Around 3 weeks is when developers that were surveyed reported they were just as productive with the RSE and they were with SEU and PDM. Afer week 3 the productivity with the RSE went higher.
Of course these results will vary depending on factors such as commitment and existing skills. There are things you can do to shrink the learning curve and maximize productivity, such as formal training and regular team meetings to share questions and tips. These are also summarized in the case study article.
One of the concerns we often hear from developers is the time it takes to use the mouse. The mouse is the easiest way to learn RDi, which basically means, by “clicking around” you can explore the user interface and find lost of the features it contains. However, power users want to use the keyboard to quickly navigate around. The good news is the RSE is full of keyboard shortcuts to enable those power users, the bad news is it takes time to memorize them so they just come naturally. I rarely use the mouse any more when working in the RSE (which becomes a problem when I have to demo and nobody can follow what I’m doing). A good place to start is the System i Developer keyboard shortcuts “pinup” (you should print it and pin it up beside your workstation).
There are many really cool features in RDi that developers like, but here I tried to focus on the business value of adopting RDi for RPG, COBOL, CL, and DDS development on IBM i. These are:
IBM i Software Developer, Digital Dad, AS400 Anarchist, RPG Modernizer, Alpha Nerd and Passionate Eater of Cheese and Biscuits. Nick Litten Dot Com is a mixture of blog posts that can be sometimes serious, frequently playful and probably down-right pointless all in the space of a day. Enjoy your stay, feel free to comment and in the words of the most interesting man in the world: Stay thirsty my friend.
Developerworks Connections Sunset – How to Extend RDi
How to Install IBM Access Client Solutions (ACS)
5733XJ1 IBM i Access Client Solutions – QuickStartGuide
Install LANSA AXES – Automatic Web Interface for IBM i (AS/400) 5250 Applications
How to get a list of all files in an IFS folder
Edit MENU with IBM i RDI
Encrypt IBM i File (Table) Data with no RPGLE changes using SQL
Cleaning messy IBM i Integrated File System (IFS) file names
How to encrypt or hide CL/RPG Source Code in ILE Debug Views