Why can’t you clone IBM i developers like you can clone sheep?

Addressing the challenge of quickly ramping up new IBM i staff

By Robert Rheault, Director of Application Services at Fresche Legacy

After seeing researchers successfully clone a sheep, the first thought that crossed my mind was, “If we could clone IBM i developers, our problems would be solved.” The population of legacy developers is rapidly dwindling due to retirement and other factors and, when you have only a few RPG or COBOL developers left, the prospect of trying to replace one of them is daunting. While I haven’t figured out how to clone developers yet, I have found out how to solve the problem of staffing our clients’ IBM i  maintenance and development projects.

Let's start by imagining a situation: Just when a trusted legacy resource is needed for a special project, that person announces retirement. Or maybe he or she won the lottery and is leaving the company (kind of the same thing!). Either way, you are now faced with two challenges: First, finding a replacement resource, and second, onboarding that person.

At this point, you probably wish you had begun planning for this sooner. 

Why onboarding is painful

Onboarding a technical resource can be a costly and disruptive process because it requires quick and efficient training that often involves the time and effort of numerous people, including other valuable resources. Add to this the possibility that a new resource can quickly lose motivation when their onboarding process is inefficient, and you have a recipe for disaster.

Have you ever seen or experienced a training process that begins by letting a new developer simply log in and poke around an application? Such a process employs trial-and-error learning, which can be stressful for the trainee and makes for a steep learning curve. It’s not an ideal situation.

Now imagine that this newly-trained resource gets discouraged and leaves after six months. This slow, painful, learn-on-your-own, trial-and-error training process has to begin all over again. When the next developer starts, he or she too will struggle through the same agonizing process. Will this person eventually come around? Or will this resource also leave? Isn’t there a way to onboard highly specialized professionals without tying up other employees or using ineffective techniques?

Making onboarding easier

After seeing numerous new employees struggle to settle into their new roles, we developed some best practices to help make the onboarding process easier:

  • When new developers start, especially legacy developers, you first need to help them understand the business. A new developer should spend time with each major business unit to understand their needs and know their daily struggles. Only then will they begin to understand the applications.
  • Each particular legacy system is a complex organism that has been customized, tweaked, improved and reorganized over time to meet specific requirements and goals. This knowledge does no good to anyone when only one developer has access to it – especially if that developer is long gone. Equally useless are the few documents that were written 10 years ago. The best way for new developers to understand where an application has come from (and where it’s going to) is for them to have access to documentation that is constantly updated by all developers working on the application. That way, if a new developer needs to visualize all details and interacting relationships of an application's files, code, variables and business rules, most (if not all) of those specifications can easily be found. 
  • Checklists can be a developer’s best friend.  Having a formalized checklist helps to not only instill best practices around process’, it also educates the developer on how things really work.  A structured training path also lets you fill in the gaps to anything that the developer might have missed in their formal training for things you expect they would have already learned. 

Using these few simple onboarding approaches will save developers, clients and employers lots of time, stress and money. There are definitely more things that can be done to make the training and onboarding even more successful (examples such as using a “buddy system” and having a detailed checklist spring to mind), but from all of the headaches I've experienced in attempting to introduce new developers to old applications, I've learned that these two steps are the most critical.

Our experience ramping up new IBM i resources

When we are hired to help companies maintain or enhance their IBM i applications, we follow the three approaches above. First, we meet with the business to understand their challenges and what they want to accomplish. That’s how we make sure our resources, who are new to the customer’s company, will become a true part of our customer’s team and will help IT meet business demands.

Then we take advantage of our automated analysis and documentation suite, X-Analysis. Our developers are experienced in using X-Analysis to accurately map and analyze customers’ applications. We are able to expose business rules, data models, code composition, dependencies, processes and flows in a fraction of the time it would take to understand an application if we were doing it manually. This quick ramping-up process allows us to onboard new resources to our customers’ teams very quickly, so we can start contributing to their IT goals. It also allows us to immediately help those customers whose IBM i resources have retired without training anyone in their system.

Rob Rheault is Director of Application Services at Fresche Legacy. He has dedicated his career to the IBM i series, first within IBM and, more recently, in the Application Services team at Fresche. He is responsible for coordinating a team of IBM i specialists who work with customers to maintain, evolve and enhance their applications in order to meet business demands.