The Quiet Power of Refactoring: Modernizing Without Rewriting

 

☕ Today’s Coffee: Starbucks Single-Origin Sumatra Dark Roast — rich, earthy, and unhurried. It’s the kind of coffee that doesn’t rush to impress you. Instead, it lingers—complex and strong. Refactoring should feel the same way: slow, steady, and quietly transformative.

The Myth of the Big Rewrite

When people talk about modernization, the conversation often jumps straight to rewriting everything.
“We’ll just rebuild it in Java.”
“We’ll migrate to the cloud.”
“We’ll replace all the RPG with APIs.”

It sounds bold. It sounds strategic. But in practice, those “big bang” rewrites are often the costliest, riskiest, and most disappointing modernization projects out there.

Why?
Because the moment you try to rebuild decades of business logic all at once, you discover how much knowledge was never written down. You rewrite problems you didn’t understand. You replace stability with uncertainty.

The better path isn’t revolution. It’s evolution.
And evolution happens through refactoring.

Refactoring as a Mindset

Refactoring is modernization in motion — small, consistent improvements that make the code clearer, safer, and easier to maintain without changing its behavior.

It’s not glamorous. It doesn’t make a flashy demo. But it’s what separates healthy systems from decaying ones.

Start small:

  • Rename a cryptic variable.

  • Convert a single subroutine to free-form RPG.

  • Replace a hard-coded constant with a named one.

  • Extract repetitive logic into a service program.

  • Add a unit test to confirm expected behavior.

Refactoring isn’t just about cleaning code — it’s about protecting behavior. That’s where unit testing and QA come in.

Each time you change a procedure, wrap it in a test. Confirm that inputs still produce the same outputs. Use automation where possible.
The goal isn’t to test everything—it’s to test the right things: the critical business rules that define your system’s reliability.

Every improvement compounds. Over time, you build a cleaner, more understandable codebase that modernizes itself naturally—and safely.

Practical Refactoring in RPG

Let’s take a small example. Suppose you have this fixed-format calculation:

C           IF   CUSTTYPE = 'A'
C             DISCOUNT = PRICE * .10
C           ELSE
C             DISCOUNT = PRICE * .05
C           ENDIF
C           TOTAL = PRICE - DISCOUNT

It works. It’s been running fine for 20 years. But it’s hard to read and harder to extend.
Refactoring it into free-form takes minutes but pays off every time someone touches it:

If customerType = 'A';
   discount = price * 0.10;
Else;
   discount = price * 0.05;
EndIf;

total = price - discount;

Then go one step further:
Move the discount logic into a separate procedure.

discount = CalculateDiscount(price: customerType);

Now, your code reads like a sentence. It communicates intent instead of forcing interpretation.

And with a simple unit test, you can confirm it still behaves as expected:

// Unit Test Example
If CalculateDiscount(100: 'A') <> 10;
   dsply 'Test failed for customer type A';
EndIf;

That’s refactoring with safety nets. No rewrite. No disruption. Just clarity and confidence.

Refactoring Databases the Smart Way

Refactoring isn’t just for code. It applies to your database, too.

Most IBM i systems still run on decades-old DDS files. They’re functional—but rigid. Expanding a field size or changing a key often means updating hundreds of programs.

Here’s the modern approach:

  • Convert one file at a time from DDS to DDL.

  • Use SQL views to decouple your schema from your RPG logic.

  • Add constraints and identity columns to enforce consistency quietly.

  • Include QA checks to confirm record counts, constraints, and key integrity before deploying.

Example:

Create or replace view ActiveCustomers as
   select CustID, CustName, CustCity
     from Customer
    where Active = 'Y';

Now, every program can use this clean, predictable view without rewriting file logic.
You’ve modernized the database — one cup at a time.

Leadership Angle: Momentum Over Milestones

Big rewrites are tempting because they sound decisive. But real modernization is about momentum, not milestones.

Refactoring works because it builds trust.

  • Developers gain confidence by improving familiar code.

  • QA teams gain confidence because tests prove the system still works.

  • Leadership sees visible progress without operational risk.

You can even track “technical debt reduction” and defect reduction rates as modernization KPIs.
Modernization isn’t a side project — it’s a daily practice. Every small improvement builds credibility and capability.

The Developer’s Role: Refactor, Test, Repeat

Developers are the stewards of modernization. You don’t need permission to refactor responsibly — just discipline and consistency.

  • Use version control and peer reviews for safety.

  • Create reusable unit test templates for common logic.

  • Partner with QA early — not just before release.

  • Document behavior changes clearly in Git commits.

  • Celebrate the small wins: cleaner modules, fewer bugs, faster testing cycles.

Every change is a chance to leave the code a little better than you found it—and a little safer.

Final Sips

My Sumatra Dark Roast doesn’t shout for attention—it rewards patience. Refactoring does the same.

Modernization isn’t always about what’s new. Sometimes, it’s about what’s better.
Cleaner code. Stronger tests. Fewer defects.

When refactoring and QA work hand in hand, your systems evolve safely—and your confidence grows with every deployment.
Because in the end, modernization isn’t one big leap—it’s a thousand small, tested steps that keep your system alive, resilient, and legendary.

☕ Follow The RPG Blend for real code, real coffee, and no-nonsense modernization insights for IBM i developers and leaders.

Comments

Post a Comment