How do you deal with large, complex systems?

The field of science that studies how programmers interpret programs is called Program Comprehension. With the world's ever-growing pile of software, it's an important subject.

Research has led to useful ways to understand what programmers do, especially those who work with legacy systems. This is particularly important in the RPG world, which exhibits persistent attrition of programmers with application knowledge.

Mental Modeling of Programs

There's broad agreement that when presented with an unfamiliar program, programmers build knowledge and construct mental models, somewhat concurrently, in these areas:

• Concept assignment—The mapping of real-world domain knowledge, e.g., business knowledge to statements or sections of code

• Data flow—A model of the data input to and output by the program, along with categorization of transformations that take place

• Control flow—A model of the sequence of operations that occur during execution, typically consisting of the primary driving loops in the program, key conditions and calls to subroutines, procedures, other programs; etc.

• Static structure—The organization of the source code, irrespective of execution, e.g., what the subroutines and procedures are, how they're connected, what data descriptions exist, etc.

• Feature location—The locating of all relevant source code pertaining to a particular feature— typically, a feature related to an assigned task

These models exist at both program and system levels. Obviously, building these mental models across many objects in a large system is far more challenging.

Here's a three-minute video on Agile Analysis of Legacy RPG Applications.

Strategies for Building Mental Models

Programmers follow different strategies, depending on their existing knowledge of the business domain and the program.

• Bottom-up—Programmers who have little knowledge of the business or the program follow a bottom-up strategy by reading lines of code and "chunking" them together. These chunks can be grouped into larger chunks.

• Top-down—Programmers who have business and/or program knowledge engage in the concept assignment and feature location functions described above and build the remainder of the models using these as drivers, resorting to chunking in unfamiliar sections.

• Beacons—Not really a strategy, but an important concept and tool: beacons are key words, phrases, or just letters  that programmers scan for based on knowledge of domain, program, and software in general. Example: scan for occurrences of "write" in the code or perhaps "discount" and other words or phrases from the business or general software domains.

Not to be dismissed is the "read code for an hour" strategy, which we've all done when necessary, using whatever we can muster of the above techniques.

Crucial Barriers to Program Comprehension

One huge obstacle to comprehending a program is something rarely identified as an obstacle and is indeed often viewed as a language feature: delocalization. In Program Comprehension, delocalization is considered a fundamental problem.

What's delocalization? Basically, it's when you have to leave the source code you're looking at and navigate to source code somewhere else to look at that. Typically, this also involves a return trip. For example:

KEYLS1   CHAIN  ITMCONTP

What are those key fields? What fields are in the file?

EXSR  CALCLINS

What happens there?

CALL  IV100R

What's in that program?

If you're unfamiliar with a program, these statements require that you leave the statement and go elsewhere to understand what's happening. While this is a great way to organize programs, it has a high cost on the process of constructing mental models.

Here's a three-minute video on Hyper-Navigation of RPG Systems.

Delocalized statements require navigation. Navigation requires thinking—specifically, short-term memory. Scientists now believe that humans are able to hold only about three items in short-term memory. Engaging in navigation requires programmers to "swap out" what they had been constructing in their minds in order to do the navigation. Will that model be swapped backed in completely and accurately? This is a key source of defects and lower productivity in maintenance tasks.

Improving Productivity and Accuracy

While the challenges of delocalization and navigation don't present the only opportunities to improve software maintenance, they're highly significant, especially because static analysis tools exist that can make a big difference. X-Analysis from Databorough is surely the most comprehensive of these tools for AS/400 developers.

A good static analysis tool enables programmers to quickly and effortlessly navigate objects, routines, definitions, etc. throughout an application, with minimal mental disruption. Few ways are more effective at improving quality and productivity of software maintenance and enhancement tasks.

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1

Steve Kilner is a leading expert in the field of static analysis, software complexity metrics, and program comprehension. He is a specialist in the maintenance and migration of legacy software systems for the IBM i and has written extensively on the subject. As the founder of and current CEO of vLegaci, he developed a combination static and dynamic analysis tool for RPG. He currently leverages his experience through his partnership with Databorough, makers of X-Analysis.

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails