Case Study 2: MedClaim's Program Structure Audit

Background

MedClaim's claims processing system contains approximately 4 million lines of COBOL spread across 1,800 programs. These programs were written by dozens of developers over twenty-five years, and the coding standards — such as they were — had changed multiple times. James Okafor, the team lead, noticed a troubling pattern: new team members were taking 2–3 times longer to understand and modify older programs compared to newer ones, even when the business logic was similar in complexity.

Sarah Kim, the business analyst, reported a related issue from the business side: change requests that should take days were taking weeks, because developers spent most of their time understanding the existing code rather than implementing the change.

James commissioned a structural audit of the system's 200 most frequently modified programs.

The Audit

Tomás Rivera wrote a series of scripts to analyze the COBOL source and extract structural metrics. The findings were revealing:

Finding 1: Naming Chaos

Paragraph names were similarly inconsistent: 40% used numeric prefixes, 30% used descriptive names without prefixes, and 30% used a mix of both.

Finding 2: Missing FILE STATUS

Of 520 SELECT statements across the 200 programs: - 210 (40%) had FILE STATUS clauses - 310 (60%) did not

Of the programs without FILE STATUS, 45 had experienced production incidents in the past two years related to file handling errors that went undetected.

Finding 3: The Period Problem

Of the 200 programs: - 72 (36%) used COBOL-85 scope terminators consistently - 58 (29%) used periods for scope control (pre-COBOL-85 style) - 70 (35%) mixed both styles within the same program

The mixed-style programs had the highest bug rate: three times more defects per line of code than the consistently-styled programs.

Finding 4: Copybook Usage

• 120 programs (60%) used shared copybooks for file record definitions
• 80 programs (40%) had inline record definitions, many of which were outdated copies of what was in the copybooks

When a record layout change was needed, the programs with inline definitions required individual updates. On average, 3 of these updates per change request contained errors (usually missing or misaligned fields).

Finding 5: Program Size and Structure

Programs with fewer than 5 paragraphs (the "monolithic" programs) accounted for 15% of the codebase but 40% of maintenance tickets.

The Response

James proposed and implemented a two-phase response:

Phase 1: Standards (immediate) - Published a formal COBOL coding standard document (modeled on GlobalBank's, with MedClaim-specific additions) - Required all new programs and all modifications to existing programs to follow the new standards - "Scouts rule" — any program touched for a change request must be brought into compliance with the new standards in the modified sections

Phase 2: Refactoring (ongoing) - Identified the 30 most-modified programs for priority refactoring - Each refactoring included: consistent naming, FILE STATUS on all SELECT statements, scope terminators replacing period-based scope, copybook adoption for all record definitions, and comment headers - Refactoring was done as dedicated work items, not combined with feature changes, to isolate risk

Results After One Year

• Average time to implement change requests decreased by 35%
• Production incidents related to file handling decreased by 60%
• New developer onboarding time (to first productive contribution) decreased from 8 weeks to 5 weeks
• Developer satisfaction scores (internal survey) increased significantly

Analysis Questions

1. The audit found that mixed-style programs (combining period-based and scope-terminator-based code) had the highest defect rate. Why would mixing styles be worse than either style alone?

2. James chose the "scouts rule" approach — improve code quality incrementally as programs are modified. What are the advantages and disadvantages of this approach versus a dedicated refactoring project?

3. Why did the 40% of programs without FILE STATUS have higher incident rates? What specific types of failures go undetected without FILE STATUS?

4. The audit used automated scripts to analyze structural metrics. What specific metrics would you measure if conducting a similar audit? (Name at least five.)

5. Some developers resisted the new standards, arguing that "if the code works, why change it?" How would you respond to this argument?

Lessons for Students

• Code structure directly impacts maintenance cost. The audit proved quantitatively that poorly structured code takes longer to understand and change.
• Consistency matters more than any specific convention. Whether you use WS- or W- as a prefix matters less than using the same prefix throughout the system.
• Missing FILE STATUS is a ticking time bomb. The programs without it worked fine — until they did not, and when they failed, the failures were silent and expensive.
• Standards are not bureaucracy — they are investment. The time spent establishing and following standards pays back many times over in reduced maintenance cost and fewer production incidents.