Big gains can be realized by focusing on what RPG programmers actually do.

By Steve Kilner

For the past few decades, while software development has traveled through a long list of new languages and methodologies, a lesser-known journey has been underway: seeking to maintain all the software already created. In the field of software maintenance, an important discipline, often labeled "program comprehension," has developed.

On a daily basis, IT organizations that support RPG applications come face to face with the theories and issues that embody this field. As RPG staffs are reduced, either through attrition or budget cutbacks, this field of research holds increasingly important value for developers, programmers, and managers who must keep important business applications running.

Program comprehension has the sound of something whose hard value might seem a little squishy and difficult to pin down. But consider this brief list of facts, all based on multiple, serious academic studies:

• An estimated 70-90 percent of the lifetime cost of custom software is spent on maintenance of the software.
• Maintenance developers spend 40-60 percent of their time trying to understand the programs they maintain (i.e., program comprehension).
• A full 50 percent of the time that maintenance developers spend trying to understand programs is spent seeking information about what they are looking at in the program.

Doing the simple math on the first two bullets leads to the possible conclusion that the single most costly task in the entire software lifecycle is for maintenance developers to figure out what programs do.

Before we get into detail about program comprehension, let's understand a few basic facts about software maintenance to set the overall context.

Software Maintenance Context

The ISO defines four types of software maintenance:

•·      Corrective maintenance corrects discovered problems.

•·      Adaptive maintenance keeps software usable in a changing environment.

•·      Perfective maintenance improves performance or maintainability.

•·      Preventive maintenance corrects latent faults in the software before they become effective faults.

All IT organizations deal with these four types to varying degrees.

Another important concept is what has been called the Laws of Software Evolution. These are typically defined as eight laws, but for practical purposes there are really only two:

•·      Software must continually change to maintain its usefulness.

•·      As the software changes, it becomes increasingly complex unless work is invested to prevent this.

The first one is important because, if it is true, it provides the reasoning why users of software must plan for continual maintenance expenditures over its lifetime. The point has an underlying, obvious truth that makes it easy to accept as true: all human organizations (businesses) change over time, and if their supporting software does not change with them, it will become less and less valuable.

The second law is important for a different reason: it explains to organizations why their software becomes more "decrepit" over time. The underlying truth here is this: when a new software application is first developed, all of its features are taken into consideration to create the optimal design for that set of features. Later, as more features are added, the overall design cannot be re-optimized; the additional features are increasingly attached like barnacles to a once-sleek hull. Eventually, they weigh down the original vessel, and there is little in the way of well-crafted design that can be perceived.

Program Comprehension: Inside Developers' Heads

Over the last two decades, a fair amount of research has been done to determine how developers approach the task of understanding an unfamiliar program. These are a few commonly used concepts and their terms:

•·      Mental model--Mental representation of the program

•·      Cognitive model--The processes and information in the developer's head as the mental model is constructed

•·      Code scenarios--Familiar, commonly used fragments of code or code patterns

•·      Beacons/landmarks--Recognizable, familiar code features or techniques that are cues to the presence of significant functionality

•·      Rules of programming--Understood programming standards and conventions

Developers use different strategies to go about understanding a program, depending on their knowledge, skill level, and the assigned task.

In the "top-down" strategy, a developer begins with a hypothesis about the nature of the program based on the developer's existing domain (application or business) knowledge and attempts to map that to the code. The hypothesis and mapping to the code is then refined iteratively by developing child hypotheses. Expert programmers heavily use code scenarios, beacons, and rules of programming in this process. Often complicating this effort are calls to external objects or entities.

In the "bottom-up" strategy, developers start by reading individual lines of code and grouping them into higher-level abstractions ("chunking"). These abstractions are then iteratively grouped into further higher-level abstractions. In this strategy, the developer typically first forms a mental model of the program's control flow (plus key events) and then develops a model of the data flow.

Depending on their knowledge, skill level, and the task at hand, developers may sometimes choose the "as-needed" strategy. In this case, the developer mostly examines only the code judged to be relevant for completing the assigned task. This often proceeds in a top-down manner as the developer attempts to navigate what is judged to be only the relevant program hierarchy. With the use of this strategy, the developer often does not form a robust mental model of the program. This is potentially faster, but it runs the risk of an increased likelihood of errors.

Whatever strategy is employed, a well-formed mental model of a program will always include understanding of...

• The object/function/subroutine hierarchy
• The control flow of the program
• The data flow of the program

One of the key tasks in any of these strategies is information seeking and the management of that process. As an example, take the following statement:

      C              MOVE  FLDA           FLDB

The reader can imagine all the possible information he or she might seek about that statement: what the FLDA attributes are, what file it's from, what might be in FLDA at this point, where the file is read, whether FLDA is in a data structure, what conditions govern this statement, etc. Finding all this information involves "forward-chaining," "backward chaining," and "side-chaining" through the source code.

Investigating those questions leads of course to more questions, which means the developer must track a network of answered and unanswered questions. The quality of the maintenance process depends heavily on the developer's ability to manage that question network correctly, and this relies heavily, of course, on something we all know to be imperfect: human memory. One of the most significant sources of maintenance defects is the failure of developers to seek all the information they should, either because of insufficient domain knowledge, poor decision-making, or simple forgetfulness.

When one is thinking about what is inside developers' heads, one must also consider the fact that not all heads are on equal footing (so to speak), either in skill levels or in domain knowledge. Less-experienced developers tend to think in terms of "objects" (e.g., programs, files, screens, subroutines, etc.), whereas more-experienced developers think about these things plus the relationships between them and their relationships to the system as a whole. Mindfulness of the broader context is one of the keys to the lower defect rate of expert developers.

Program Comprehension Tools and Techniques

There are two categories of methods for program comprehension, and most tools and techniques fall into one of them:

•·      Dynamic Analysis

•·      Static Analysis

In dynamic analysis, developers use run-time information, such as execution trace data, to analyze and understand the program. For example, some tools on the market, in other languages besides RPG, attempt to convert trace data into UML sequence diagrams. This is usually more feasible in object-oriented environments. IBM provides some very basic tools for dynamic analysis on the System i, centered around the Start Trace (STRTRC) command.

In static analysis, developers use source code, object code, and other available artifacts to analyze and understand the program. Typically, different views of the program are presented in the form of different textual views of the source and visual views of program structure or flow.

A tool that supports static analysis for RPG would include features for forward and backward chaining, variable reference, program hierarchies, control flow analysis, data flow analysis, management of the information-seeking process, and so on.

RPG shops that continue to rely on SEU or other simple editors for the task of program comprehension in software maintenance have a significant opportunity to improve their productivity and quality, keeping in mind the research results showing that approximately half of maintenance developers' time is spent trying to understand code.

Any software that provides any of the features listed in the previous paragraphs will bring improvements to the RPG maintenance process. Tools that contain varying degrees of RPG static analysis include IBM's WDSC/RDi, Databorough's x-Analysis, Arcad's Observer, and vLegaci's Codelyzer.

Improving RPG Maintenance

Most RPG-oriented organizations that engage in regular maintenance work can make significant improvements in their throughput and defect count. Recognition of the well-documented facts outlined in the beginning of this article is a first step. To reiterate:

• An estimated 70-90 percent of the lifetime cost of custom software is spent on maintenance of the software.
• Maintenance developers spend 40-60 percent of their time trying to understand the programs they maintain (i.e., program comprehension).
• A full 50 percent of the time that maintenance developers spend trying to understand programs is spent seeking information about what they are looking at in the program.

Assisting developers in their program comprehension effort potentially holds "big bang for the buck." Short of acquiring tools with the necessary features, there's not much else IT management can do to facilitate program comprehension. But once tools are acquired, it is paramount that 1) the tools are made available to all developers, 2) necessary training is provided to get the benefits, and 3) management follow-up occurs to make sure the tools are being fully utilized. Some developers resist changing habits developed over many years, but there is little business justification to allow less-productive, lower-quality work methods to persist.

As IT staffs face increasing challenges due to turnover or cutbacks, management must deal with the fact that more and more maintenance activity will be done by developers with less and less program familiarity. Assisting the program comprehension task directly is a straightforward way to mitigate the steep learning curve these developers face--and the extra cost and risk the organization potentially incurs.

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails