Guru: Cohesion First – What A Procedure Should Be Responsible For

April 6, 2026 Gregory Simmons

One of the easiest mistakes to make in procedure-driven RPG is assuming that small procedures are automatically well-designed procedures. They are not. Size and cohesion are related, but they are not the same thing. A cohesive procedure has a single, clear responsibility. It exists to answer one business question or perform one business action. When a procedure tries to do more than that, it stops being a reusable building block and starts becoming a liability.

In procedural RPG, nothing enforces this discipline. There is no compiler warning when a procedure quietly takes on a second responsibility. There is no language feature that prevents a developer from adding just one more step because it happens to be convenient at the time. Over years of maintenance, those conveniences accumulate and cohesion erodes almost without notice.

If You Cannot Name It Clearly, It Is Doing Too Much

Naming is one of the most reliable cohesion tests available to an RPG developer. When a procedure name requires vague wording or starts to feel hand-wavy, that is often a sign that multiple responsibilities have been bundled together. Names like ProcessMushroomOrder or HandleMushroomInventory sound reasonable at first, but they conceal behavior rather than describe it.

Clear names force clear intent. A procedure named ValidateMushroomBatch sets an expectation. A procedure named CalculateMushroomYield tells the caller exactly what problem it solves. When naming becomes difficult, that is not a wording problem. It is a design problem.

Experienced RPG developers learn to treat naming friction as feedback rather than something to push through and ignore.

Business Actions Versus Technical Steps

Another common cohesion failure comes from mixing business logic with technical implementation details.

A procedure that determines whether a mushroom shipment meets quality standards should not also be opening files, managing commitment control, or writing audit records. Those tasks may occur as part of the same workflow, but they are not the same responsibility.

In practice, cohesive procedures tend to fall into two broad categories. Some express business intent and rules, such as determining whether a mushroom batch can be sold or calculating spoilage thresholds. Others handle technical concerns, such as reading inventory records or persisting inspection results. When those responsibilities are kept separate, procedural RPG code remains flexible and understandable. When they are mixed, every change becomes harder than it needs to be.

The Utility Procedure Trap

Utility procedures are often introduced with good intentions. A common date formatter. A reusable string cleanup routine. A helper that normalizes mushroom variety codes. Used carefully, these procedures can reduce duplication and improve consistency.

Problems arise when everything starts to look like a utility. Over time, many RPG systems accumulate service programs filled with loosely related procedures that exist simply because multiple programs needed them at some point. These service programs lack a unifying concept, and cohesion is lost at the module level even if individual procedures remain small.

Loosely purposed service programs also create fertile ground for cyclical dependencies. When a service program exists as a general collection of helpful procedures rather than a clearly defined capability, it inevitably begins to depend on other service programs that are just as loosely defined. Over time, those dependencies start to point in both directions. What begins as a convenient reuse decision, turn into service programs that present difficulties when compiling, tested, or reasoned about independently. Cyclical dependencies are not an accident. They are a structural signal that cohesion was lost earlier and never reclaimed.

A cohesive service program should represent a domain or capability, such as mushroom inventory management or quality inspection rules. When it becomes difficult to explain what a service program is responsible for in a single sentence, it has already grown beyond its useful boundaries.

Cohesion Is What Makes Reuse Safe

Low cohesion does not just make code harder to read. It makes reuse risky. When a procedure does more than its name or interface suggests, calling it in a new context becomes an act of faith. Developers begin to rely on side effects they do not fully understand, or they avoid reuse altogether and duplicate logic instead. Both outcomes slowly degrade the system.

Highly cohesive procedures behave predictably. A procedure that calculates mushroom shelf life should do exactly that and nothing more. That predictability is what allows procedure-driven RPG systems to scale over time without becoming fragile.

Cohesion Is a Daily Decision

Cohesion is not something that is designed once at the beginning of a project and then forgotten. It is a decision made every time a procedure is modified.

The moment a developer thinks, I will just add this here since I already have the mushroom data loaded, a design decision is being made. Sometimes that decision is justified. Often it is the first step toward a slow design failure that will not become obvious for years.

Procedure-driven RPG rewards developers who pause at that moment and ask a simple but uncomfortable question. Is this still the same responsibility? When the answer is no, the correct response is rarely the most convenient one. It is almost always the right one.

Until next time, happy coding.

Gregory Simmons is a Project Manager with PC Richard & Son. He started on the IBM i platform in 1994, graduated with a degree in Computer Information Systems in 1997 and has been working on the OS/400 and IBM i platform ever since. He has been a registered instructor with the IBM Academic Initiative since 2007, an IBM Champion and holds a COMMON Application Developer certification. When he’s not trying to figure out how to speed up legacy programs, he enjoys speaking at technical conferences, running, backpacking, hunting, and fishing.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search