Case Study: MedClaim — Applying Coding Standards to CLM-ADJUD

Background

When MedClaim Health Services needed to hire three new COBOL developers to handle a backlog of regulatory changes, James Okafor recognized a problem: the existing CLM-ADJUD codebase had no consistent coding standards. Different sections of the program reflected the styles of the twelve developers who had contributed to it over the years.

Some paragraphs used numeric prefixes (3000-VALIDATE); others used descriptive names without numbers (VALIDATE-CLAIM). Some checked FILE STATUS religiously; others didn't check at all. Comment styles ranged from elaborate block headers to zero documentation. Variable names ranged from descriptive (WS-CLAIM-ADJUDICATION-STATUS) to cryptic (WS-X7).

For the existing team, this inconsistency was manageable — they knew the code intimately. But for three new developers learning the system, the inconsistency was a significant barrier to understanding.

Developing the Standards

James assembled a working group: himself, Sarah Kim (business analyst), Tomás Rivera (DBA), and one representative from the new hires. They developed their standards over two weeks, following these principles:

1. Evidence-based: Every rule was justified by a defect pattern or readability concern. No rules existed "just because."
2. Enforceable: Every rule could be checked either by a tool (SonarQube) or by a simple checklist item. Subjective rules ("code should be elegant") were excluded.
3. Incremental: Existing code would not be required to meet the standards retroactively. Standards applied to new code and to any existing code that was modified.

The Controversy: Comments

The biggest debate was over commenting standards. One camp argued for minimal comments ("self-documenting code is better than comments that get out of date"). The other camp argued for thorough comments ("COBOL is inherently verbose; we need comments to explain WHY, not WHAT").

The compromise: paragraph-level block headers are required (explaining purpose, inputs, and outputs). Inline comments are required only for non-obvious logic. Comments describing what a COBOL statement does ("Move zero to counter") are prohibited — they add noise without value.

The Controversy: GO TO

James initially proposed an absolute ban on GO TO. Tomás pointed out that the established error-handling pattern in CLM-ADJUD used GO TO for exit paragraphs:

       3000-VALIDATE-CLAIM.
           IF CLM-MEMBER-ID = SPACES
               MOVE "E001" TO WS-ERROR-CODE
               GO TO 3000-VALIDATE-EXIT
           END-IF
           IF CLM-AMOUNT NOT NUMERIC
               MOVE "E002" TO WS-ERROR-CODE
               GO TO 3000-VALIDATE-EXIT
           END-IF
           ... (more validations)
           MOVE "0000" TO WS-ERROR-CODE.

       3000-VALIDATE-EXIT.
           EXIT.

The team decided to allow GO TO exclusively in this pattern (early exit to a paragraph's exit point) but prohibit it in all other contexts. This was documented as the "structured exit pattern" exception.

Implementing with SonarQube

MedClaim purchased the SonarQube COBOL plugin and configured it with their custom rule set. Key rules:

The Quality Gate

SonarQube's quality gate defined the minimum bar for code promotion:

• Zero critical issues
• Fewer than 3 major issues
• Code coverage greater than 60% (measured by unit tests from Chapter 34)
• Duplicated lines less than 5%

New code that failed the quality gate could not be promoted to the integration test environment.

The First Test: Telehealth Module

The first program written under the new standards was the telehealth adjudication module (CLM-ADJUD-TELE). One of the new developers, working under James's guidance, wrote the 1,847-line program in three weeks. It passed the SonarQube quality gate on the first scan — zero bugs, zero code smells, zero duplicated lines.

James compared the SonarQube report for CLM-ADJUD-TELE against the report for the legacy CLM-ADJUD:

The Boy Scout Rule in Practice

Over six months, the team applied the "boy scout rule" — improving standards compliance whenever they modified existing code. Progress was tracked in SonarQube:

By month 6, the legacy CLM-ADJUD had dropped from 42 issues to 12, without a dedicated refactoring project. The remaining 12 issues were all in paragraphs that had not been modified during the period.

Onboarding Impact

The most significant benefit was onboarding speed. The three new developers reported:

• Developer A: "The standards made it obvious what each paragraph was supposed to do. I didn't need to ask James every time I encountered unfamiliar code."
• Developer B: "The SonarQube feedback was like having a senior reviewer available 24/7. I learned the patterns faster because the tool caught my mistakes immediately."
• Developer C: "Coming from a Java background, I expected COBOL to be chaotic. The standards made it feel familiar — same principles, different syntax."

James estimated that onboarding time decreased from an average of 12 weeks (for the team's previous hires) to 6 weeks for the new developers.

Discussion Questions

1. The team allowed GO TO in the "structured exit pattern" but prohibited it everywhere else. Is this a reasonable compromise, or does it create a slippery slope? Would you have made the same decision?

2. Standards were applied to new and modified code only — not retroactively to existing code. What are the advantages and risks of this incremental approach? When might a retroactive mandate be justified?

3. The SonarQube quality gate requires zero critical issues. Is this too strict? What happens if a critical fix is needed urgently and the program has a pre-existing critical issue in unrelated code?

4. Developer C commented that COBOL "felt familiar" under the new standards. What does this suggest about the universality of code quality principles across programming languages?