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

After seeing researchers successfully clone a sheep, this was the first thought that crossed my mind: “If we could clone IBM i developers, our problems would be solved.”

The population of legacy developers is rapidly dwindling 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’ projects.

Let's start by imagining a situation in which, right 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 fact that a new resource can quickly become unmotivated 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 extremely stressful 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, I jotted down a few ideas of how to 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, 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.

Using these two 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.

Want to learn more about how we solve resource challenges? Contact Us