A famous editor once said, "You know how when you tighten a bolt on your engine the front bumper falls off?" That started me thinking of writing about how difficult it can be to modify an existing application. Oh, all right. It was her idea from the beginning. So what.

In the beginning, an application was written from scratch. And it was beautiful to behold. It did what it was supposed to do, and the logic flow was as clean and as clear as you could reasonably expect it to be. And it lived happily with a dozen unicorns, a handsome prince who liked watching romantic comedy movies, and a beautiful princess with long hair and a diaphanous gown.

But then, somebody decided that some changes needed to be made to it. So they modified the code to show the customer AR Tariff code. And suddenly, one of the unicorns disappeared and was replaced by a hippo.

A little while went by, and someone decided that what would really be helpful would be to keep the current AR Tariff code plus the previous AR Tariff code. And two more unicorns vanished, replaced by a hippo and a rhino, and the prince suddenly had some definite bulging around the mid-section.

It wasn't too much longer before someone else realized that the real problem was that they needed an AR Tariff code history going back to 1850. And OMG, what is that on the face of the beautiful princess with the long hair and diaphanous gown? Oh, yeah, those are definitely crow's feet. Plus if the wind blows that gown around…cellulite.

And that, ladies and gentlemen, is the story of our lives on the IBM i. We write applications, and then as time goes by and the modifications pile up, those apps become uglier and uglier. In the end, they enter a dark forest, where the trees fight against each other for survival and life forms that we can't imagine without hallucinogenics slink from shadow to shadow.

'Tis an evil fate, my friends. But raise your tankards high because there are some things you can do to prevent this when you develop your apps.

A Disclaimer

Let's start with a simple disclaimer. There's no way that you can prevent the scenario described above if you keep the BOP (Big Ol' Program) agenda developed with a waterfall methodology.

I know everyone wants to get some magic mantra, some special RPG op code, some ILE or Web language bailout that will get you out of this, but here's the deal. Ain't happening. There's no easy road to improved systems.

Modularity

This is where it starts. If you don't do modular, you can't expect to be able to change your app and not have it potentially trigger Armageddon. Armageddon? Maybe that's a bit over the top. Or maybe it isn't! Let's face it, bro. We live in a castle under attack by the forces of Windows. And all it takes for the castle to be taken is one person who says, "Oh, remember when we had that fiasco with the AR Tariff thing?" And suddenly the CFO is looking at a Windows-based system that says it provides "full AR Tariff functionality." Am I wrong?

So how does modularity help? Seriously, we have to go through this again?

Programs begin to go awry when they get too big. What is too big? Anything that contains more than one logical idea. I honestly don't believe that we can really handle more than one idea at a time, so cramming a bunch of them into a single section of code seems like asking for trouble. The problem is, this begs the question: what is one logical idea? Is it entering an order? Is it entering the order header information? Is it entering the customer number and validating that?

We have to be honest here. You can take modularization so far that it becomes counter-productive, like setting up a module that just prepares the entered customer number for the file access module. To be honest, I am, like T. Rex and Chuck Berry, "still thinking" about what a logical idea is, but my gut feeling is that it is a page of code. If you have to page down, then that requires remembering what is on the first page. And if you don't have the page full, it seems like a waste of space. Do you think it's weird to think of it that way? Welcome to my world.

Maybe the real problem for us is that modularity and RPG have not historically hung out together, but by using ILE concepts that can certainly happen.

Data Coupling

We don't talk much about data coupling anymore. It was all the rage back in the '80s. And I think it's still very much an issue.

Data coupling refers to something that is rampant in RPG code, a given variable being used all over the place. Initially, the solution for this was the subroutine, but in my mind that actually made the problem worse because it allowed us to use a global variable in many non-sequential spots of the program. And that's the danger in data coupling.

To some extent, using subprocedures in ILE is a fix for this but only with a caveat. If we use subprocedures like they're subroutines, then there's no benefit. But if we use subprocedures in the web sense, where they're performing the task of a logical idea, and we use local variables to do that, then we're making progress.

Bottom line: Any time you use a variable in more than one section of code, ask yourself if you really need to do that. Can you avoid that?

Agile Design

You don't see this mentioned very often when we're talking about RPG modifications and all that jazz. But I think it has a major impact on what happens.

Let's face it, 30 years after agile programming was developed, it still isn't really being used. The powers that be, who are often not project management specialists, don't see the need for it. In fact, the dominant project management strategy in the RPG world for the past 30 years has been for a programmer to start coding and let people know when they can test it. And if a project management methodology is used, it is generally waterfall because everybody wants everything mapped out ahead of time so that they don't "miss anything."

Please. When in your life have you been able to map everything out ahead of time? And you really think you're going to be able to do it with a software project?

Waterfall is based on the premise that the initial projection of the project is going to be pretty identical to the completed projection. But we know that's not true. Like Heisenburg's uncertainty principle, just talking about a project and documenting it changes how we feel about it and how it will look.

Agile is the only way to make progress yet allow things to remain fluid. But nobody will pay attention to that because we just can't shake the belief that we need to know what we're doing in total before we start. It can't possibly be that we can start slow and evolve into the system of our dreams as our understanding of what we want evolves. Oh, no.

But that's the way things really work in the real world, unfolding and becoming visible over a period of time, changing and growing as they go. Our failure to embrace agile programming is a very key contributor to the fact that even new systems need to be changed, sometimes drastically, almost before they're finished. Please, don't get me started.

Summary

In a perfect world, there would be no changes to our applications. But that's not the way it works. So what can you do to protect yourself from the future?

First, go modular. Reduce the size and complexity of the code modules you're dealing with.

Second, pay attention to data coupling. If your modularization program has been done well, data coupling will be near zero; if not, well…. Just remember, you can't understand what's happening to a data element if it's strewn halfway across the galaxy.

Third, embrace agile design. It lets you work your way into an application, forces people to confront what they said they want, and gives the chance to adapt your application before it goes too far.

Hope this helps. C ya!

David Shirey is president of Shirey Consulting Services, providing technical and business consulting services for the IBM i world. Among the services provided are IBM i technical support, including application design and programming services, ERP installation and support, and EDI setup and maintenance. With experience in a wide range of industries (food and beverage to electronics to hard manufacturing to drugs--the legal kind--to medical devices to fulfillment houses) and a wide range of business sizes served (from very large, like Fresh Express, to much smaller, like Labconco), SCS has the knowledge and experience to assist with your technical or business issues. You may contact Dave by email at This email address is being protected from spambots. You need JavaScript enabled to view it. or by phone at (616) 304-2466.

---

MC Press books written by David Shirey available now on the MC Press Bookstore.

		21st Century RPG: /Free, ILE, and MVC Boost your productivity, modernize your applications, and upgrade your skills with these powerful coding methods. List Price $69.95 Now On Sale

Also Read

What Change Control Is

Debunking Those Change-Control Myths

Application Lifecycle Management: Some Definitions (and Misconceptions)