If it's not all about new tools and GUI screens, then what is it about? Here's a hint. It doesn't use nuclear power or fuel cells, but it is pretty modern.

Last month, we started looking at the idea of modernization and what it meant. And I thought that would pretty much do it. But, as it turned out, it took the entire article to talk about how the current way of thinking about modernization (as a technical task that involves changing the tool set we use to develop apps and its fixation on SQL and GUI) was not necessarily the whole story on what modernization really is all about. So I'm extending this topic a bit today (and maybe even once more later) so that we can discuss this topic in detail. I hope you're not disappointed.

So What Is Modernization About?

So if modernization is not solely (or even primarily) about changing your tools or redesigning your screens, then what is it about?

Modernization is about making the application "more modern." But what does that mean? Isn't transferring the screens over to GUI or making a prettier GUI using flat design or some new CSS functionality a way of making them more modern? And the answer is yes, of course, but going to GUI screens from something else is like deciding you are going to shower and comb your hair before going to a bar. You may attract a higher class of guy (or girl), but in the morning you're still going to be the same old person and they're going to have to deal with it. Hmmm, maybe my wife is right; maybe I'm watching way too much of The Big Bang Theory.

What you really need is a more basic makeover than that.

The first thing you could do (and the one I want to deal with this month) is remake yourself surgically. Let's face it; you're not going to attract anyone top-notch with that nose. And you definitely need to do something about how tall you are. And a little lipo might be a real smart move.

What's the programming equivalent of this kind of makeover? One word. Modularization. You need to go in and surgically cut your program up into modules, which is from the Latin moduli, meaning "from one comes many" (or something to that effect).

What's the matter? Chicken? Afraid to cut your 20,000-line program up into a bunch of pieces? Whatsamatta, baby? Afraid you won't be able to put Humpty Dumpty back together again?

Valid fear. I can dig it.

Modularization

But if you really want to modernize a program (and another word for modernize should be strengthen or improve), you have to go the modularization route. After all, what could be more dangerous than marching into the future with a program that is, in places, almost indecipherable? If you're an experienced programmer and there are parts of a program that you hope you will never have to go into, then you have a problem with that program. Besides, we have no idea what the future will hold. Know any kids in high school? Ever think about what it will be like when they hit the job market? Want one of them to be fooling around with this program? I thought not.

But busting a program up into pieces is not an easy task. How do you go about it?

There are probably many approaches to this, and it does depend somewhat on how complex the program is, but there's one thing you can count on: you are not going to be able to go in and just copy segments of code from the Big Ol' Program (BOP) to a clean, new module.

Most BOPs are too intertwined to do that. There is too much coupling of the data elements between the different segments of the code to allow that to happen. So what you have to do is, rather than splitting the BOP apart, use it as a guide to build up your new modules almost from scratch.

First Step: Analysis

The first thing you have to do is develop a solid, high-level description of what the BOP is doing. Is it displaying a screen, what files does it use, what basic processing is it doing, what field values does it validate, etc? What you're trying to do is determine what modules you are going to need. If we assume you do everything in the Model-View-Controller (MVC) format, then we'll be looking at developing a control module, a view module (whether that be in PHP, or some other web language, or just DDS), and multiple model modules where we will keep the essential logic.

Let's assume you are modularizing an online application.

The starting point is the screen analysis, just like we talked about last month. Do the fields on the screen make sense (that is, is someone actually using them?), is there anything missing, how is the positioning, how often do you have to stop keying and do something else, how often is your concentration broken as you fill this out, are their multiple pages, etc.? Once you have improved your screen through a thorough analysis, then you can develop the code (either DDS or, if you're going GUI, something in an appropriate language) that is required to present this page.

Second Step: Control Module

The next step is to develop a control module. If you're doing a GUI screen, I suggest using RPG. The first step in the testing can be to ensure that your new control module passes control to and from the screen just as it should. In addition, for those branches that involve actual processing, you'll need to add in slots for calling the appropriate model modules (see below). The control module is the nerve center for your program.

If you're doing a batch program and there's no screen involvement, then the control module will be similar to a main program. Its primary purpose is not to react to command keys but rather to pass control to the various modules that have the program logic.

Step Three: Model Modules

I would have named this differently if they had asked me. I would have called it logic modules or something like that. Model really doesn't convey anything to me, but they (whoever they are) thought up the name, they passed on running it by me, and the rest is history.

The last step—and this is the one that will take the longest—is to build the model modules. These are the modules that will contain the program logic that's used to accomplish whatever this application is doing.

Like I said above, the logical thought is to start looking through the BOP and trying to copy code segments over to the new module. And this may be possible for some of the subprocedures, but even then I would be very careful as many of the old routines that I have seen do multiple things and often are more a section of code that was done at one point in time rather than an encapsulation of a logical idea.

And that is the essence of modularization—looking through the BOP, understanding what it's doing, and defining that action as a series of single logical ideas. Each one of those logical ideas then becomes a module.

The End—Get Out!

And that's it, a very short description of how to go modular. It sounds easy and it can be (well, more or less) as long as you're willing to think things through before you start to code. Frankly, that's hard for us in the procedural world because it seems that you can think and code simultaneously. I don't think that's as much of a problem in the OO web world, where you have to define things (classes, functions) up front before you can really do much.

But the most important thing to remember is that modularization is not just for big, scary programs. It's the way things should be done, and it should become a way of life for your career.

What's next? Well, there's one more thing to modernization, and as soon as I think of it, I'll let you know. Hopefully, that will occur to me before next month.