Want to know what a bad day looks like? Imagine you’re a developer working your way up the career ladder. One day your manager comes by your cube to tell you that you’ve been assigned to implement a critical, new feature in the company’s premiere application. You’re elated. At last you get to show off your coding mettle.

You spend the next two weeks working day and night to get the feature out. Finally, it’s time for release. You send out a pull request to merge your code into the codebase. Everything should be peachy. You can taste the stardom at hand. The next thing you know, your inbox starts to fill with emails complaining that your new code has broken the build. Turns out that the third-party libraries your code uses are older versions that have long since been deprecated. The code that works fine on your local system is causing havoc in the general codebase. Everything is going haywire. What should have been your hour of glory has turned into an episode of embarrassment and shame.

You Have Entered Dependency Hell

Anybody who has been coding for any amount of time has been in dependency hell. Those of us who programmed in early versions of Windows called it DLL Hell. Java developers have been burned by third-party .jar files that just don’t jibe as code moves down the release cycle. To this day, there is a legion of Python developers out there who are still struggling with the challenges of getting Python 2.7 code to work in newer Python 3 environments. Node developers face ongoing issues transitioning legacy code from ECMA 5 to ECMA 6. Dependency mismatch issues have been a problem throughout the history of software development. Mainframe developers have been blindsided by unknown dependencies since early batch jobs were run under JCL. Dependency mismatches are real and they hurt, sometimes too much.

So, What’s to Be Done?

The software industry has not been asleep at the wheel when it comes to solving the problem of dependency management. In fact, making dependency management easier—degrading it from likes of extreme dental pain to an addressable issue akin to an annoying muscle ache—has been a mostly successful undertaking.

One of the early goals of the .NET framework was to do away with DLL Hell. (DLL Hell is a corruption condition in DLL dependency referencing caused when COM objects declared in the Windows Registry are out of sync with the calling code.) .NET avoids the Registry altogether and references DLLs directly using the file system or the more easy-to-manage Global Assembly Cache (GAC).

Maven, a very popular Apache Project, brings a significant degree of order to dependency management for Java developers. Maven’s Project Object Model (POM) allows developers to declare exactly which version of .jar files their code needs to use. (See Figure 1.)

Figure 1: The Maven Framework for Java development allows projects to declare dependency versions

Babel allows Node developers to move between ECMA 6 and ECMA 5. 2to3 is a program that will convert code written in Python 2 to version 3.

Clearly, most programmers have confronted the issue of dependency management when developing new code. And, the industry has been active trying to lessen the burden of dependency management when introducing new code into an existing codebase. But addressing ways to management code dependency is not confined to PC-based computing; the mainframe community is actively addressing the issue, too.

Which Brings Us to Mainframes

The fact that code quality degrades of over time is not so much due to incompetent programming but rather the demands of continuous revision and the fast fixes put in place to meet the requirements of the moment. Sometimes down-and-dirty code that works today is preferable to more elegant approaches that will take months to implement.

In the mainframe world, there can be decades’ worth of these type of fast fixes in play. Trying to improve code can be a roll of the dice. Usually what gets broken is a dependency well beyond the immediate scope of programming activity. As mentioned earlier, dependency management has always been difficult. That’s the bad news. The good news is that the mainframe community is keenly aware of the problem dependency management and has done something about it. IBM’s solution, System Z’s Application Discovery and Delivery Intelligence (ADDI), is particularly adept at addressing the issue.

ADDI is a big product with a lot of features. One of the more interesting features is the Analysis Browser, which allows a mainframe developer to get a detailed understanding of all the dependencies in a particular application.

Figure 2: IBM Z ADDI Analysis Browser allows developers to visually understand code dependencies and program accordingly.

Having a clear, visual picture of all the dependencies in mainframe application is a very big deal. Mainframe code is by nature onerous. There are a lot of parts that are hidden due to the immensity of the technology. Using human intelligence to try to figure out all the dependencies in force takes too much time. Hence, a tool such as Analysis Browser is indispensable when it comes to addressing the age-old problem of dependency management.

We’re All in This Together

In the past, identifying dependency problems usually resulted in someone getting woken at 3 a.m. to fix a mission-critical problem. Using a proactive tool such as ADDI’s Analysis Browser allows more people to get a lot more sleep. Comprehensive dependency management does not need to be the result of ongoing catastrophes in production; rather, quite the opposite.

The first step to reducing the risks and calamities caused by dependency misalignments in code is to make a commitment to address the problem. The world of software development is littered with teams who just want to get through the current release and are more than happy to repeat the insanity dependency hell all over again in the next one. The excuses vary from, “We don’t have the time to do a solution,” to, “It may not be the best way to do it, but I’ll always have a job.”

Once a commitment is made, then it’s a matter for tools and process. You use the tools to determine risky dependencies. You follow process to improve the release.

Whether you’re in a distributed shop that embraces ephemeral, on-demand provisioning or a more mature mainframe shop working with Big Iron, the fact is that reliable dependency management is critical for the well-being of the enterprise. Yes, while it’s true that the details of coding and code management will vary from an IBM Z to an AWS cloud instance, the underlying thinking that brings good dependency management together is strikingly similar. As just mentioned, it’s a matter of tools and processes.

In terms of implementing ways of dependency management that work, we might be speaking different languages. But, when you take a close look at the basic concepts behind effective dependency management, you’ll find we’re all saying the same thing.

— Bob Reselman