LongEx Mainframe Quarterly - August 2022
Most sites I work with have an Integrated Development Environment (IDE) like IDz, Compuware Topaz, or Zowe Explorer. And this is good news: those sites are able to leverage the benefits of their IDE. But for most of these sites, there's also bad news: few staff actually use this IDE. Most continue to use ISPF, and I see this as a problem.
Although IDE software is pretty, few sites will be implementing it because of the nice screens and colours. Most will be looking for productivity benefits from this IDE. And those benefits can be sexy. For example, an IBM benchmark measured a 50% reduction in time required to perform basic tasks when using IDz. But those benefits aren't realised if no one uses the IDE.
Sites will also implement an IDE to get junior staff new to the mainframe up and running faster. With an IDE, a new programmer doesn't need to know ISPF or TSO, or even JCL. IDEs will be far more familiar to them, and some of the tools will detect their errors before they make them.
IDEs also help new staff that aren't mainframe newbies: it allows them to be productive a lot faster. IDEs can be setup with standard jobcards, or even generate JCL. Using an IDE, new programmers don't need to hunt around for copybooks, includes and JCL libraries. IDEs can be configured to help new hires navigate source code management (SCM) environments, understand which z/OS system they should logon to, and understand coding standards.
But if staff don't use IDEs, then these advantages aren't available: and resources spent on buying software licenses, maintaining the IDEs and configuring them are wasted.
I know what your thinking: "veteran programmers are familiar with ISPF and should be allowed to continue to use it: IDEs are really for juniors." And you'd be wrong. That IBM benchmark measured a 27% reduction in time for veteran programmers with over 15 years experience. What's more, junior programmers learn from senior programmers. If they're using different tools, this is harder.
If I haven't convinced you yet, think about who decides how IDEs are setup: what code snippets are included, coding standards and more. Who ensures that IDEs are configured so that sites get the maximum benefit from them? Yep, veteran programmers.
I'd even argue that other staff like systems programmers and DBAs should also be using IDEs. Not just for application code, they make coding JCL, REXX scripts and SQL faster. IDEs can be enhanced to perform some database management tasks.
Today, all of my clients are feeling the mainframe talent drain, and are struggling to find enough mainframe talent. IDEs are a cheap way of reducing the number of staff you need, and to get new staff up and running faster. Everyone, and I mean everyone, should be using them day-to-day.