Case Study 2: Rewrite or Refactor?

"The most expensive software decisions are the ones made from disgust rather than analysis."

Executive Summary

Where the first case study analyzed an existing code, this one asks you to make a decision — the single most consequential decision a technical lead faces when they inherit scientific Fortran. You are handed a working, validated, twenty-year-old FORTRAN 77 code that is slow, ugly, and critical. Do you rewrite it in a modern language, or modernize it in place? We will not hand you the answer; we will build the framework that produces the answer, apply it to a concrete scenario, and reach a defensible recommendation. This is the reasoning you were promised in §1.4, made operational.

Skills applied: the "legacy is an inheritance" ethic (§1.4); separating the value of validated numerics from the value of clean code; honest cost/risk estimation (§1.5, and the back-of-envelope habit from the exercises); recognizing where Fortran is and is not the right tool.

Background

You have just become the software lead for a research group. In your inheritance is REACTOR77, a 15,000-line FORTRAN 77 code that models heat and neutron transport in a reactor core. The facts:

• It works and is validated — its predictions have matched physical measurements for two decades, and its error characteristics are documented and trusted by the group and its regulators.
• It is slow — a full run takes 30 hours, and the group wants same-day turnaround.
• It is unmaintainable — fixed-form source, COMMON blocks everywhere, GOTO-heavy control flow, no tests, no documentation, and exactly one person who understands it, who retires next year.
• It is critical — its results feed safety analyses; being wrong is not an option, and appearing to work while being subtly wrong is the worst outcome of all.

Two proposals are on the table. Proposal R: rewrite it from scratch in a modern language (a junior engineer favors Rust; another suggests Python "for readability"). Proposal M: modernize it in place — convert to modern Fortran incrementally, add tests, then optimize and parallelize. You must choose.

Phase 1 — Name What Is Actually Valuable

The first discipline is to separate the code's forms of value, because they behave very differently under each proposal.

The key realization: the two proposals treat the first two rows completely differently. A rewrite puts the irreplaceable assets (validation, encoded knowledge) at maximum risk to gain the replaceable one (clean code). Modernization protects the irreplaceable assets while building the missing one. This asymmetry is the heart of the decision.

Phase 2 — Estimate Cost and Risk Honestly

Put rough numbers on each path (order-of-magnitude is enough — the exercise habit from §1.18–1.20).

Proposal R (rewrite). Reproducing 15,000 lines of subtle, undocumented physics is not a line-for-line translation; industry experience says a from-scratch reimplementation of validated scientific code routinely takes longer than the original and reproduces only a fraction of its capability before the budget runs out — with new bugs, and no validation until the entire thing exists. Estimate: 18–36 months, high risk, and the validation clock starts at zero. And note the language trap: Python would be slower than the FORTRAN 77 it replaces (the opposite of a goal), and while Rust is fast, choosing it discards the entire Fortran ecosystem (LAPACK, the parallel model, the team's existing skills) for no domain benefit.

Proposal M (modernize). Convert incrementally — one module at a time, each change verified against the existing output — so the code works at every step (the method of Chapter 18). Add a regression test first, using the current code as the reference, so any change that alters the numerics is caught immediately. Then optimize the hot loops (Part VII) and parallelize (Part VIII). Estimate: 6–12 months, low risk, validation preserved throughout, and the retiring expert's knowledge captured in tests and comments while they are still here.

Phase 3 — Address the Real Grievances

The rewrite camp is not wrong about the symptoms — the code genuinely is slow and unmaintainable. The error is assuming a rewrite is the only cure. Map each grievance to what modernization does about it:

• "It's unreadable." → Convert to free-form, implicit none, meaningful names, and modules. This alone transforms readability, and it is mechanical and safe.
• "It's slow." → You cannot profile what you cannot build cleanly; modernize first, then profile (Chapter 28) and optimize the 20% of code that holds 80% of the runtime. A 30-hour run reaching same-day turnaround is a realistic target through optimization and parallelism, without changing the science.
• "Only one person understands it." → The modernization process itself — reading every routine to convert it, writing a test for each — is how the knowledge transfers out of one head and into the code, and it must happen before that person retires. This is the most urgent item of all.

Phase 4 — The Recommendation

Modernize (Proposal M), starting immediately, prioritizing the knowledge-capture that the retirement deadline forces. The recommendation follows directly from Phase 1: the code's irreplaceable value is its validated numerics and its encoded physics, and only modernization protects them. The rewrite would trade the assets you cannot recreate for one you can build anyway, at higher cost, higher risk, and — in the Python case — worse performance.

The one honest caveat, and the mark of real judgment: this recommendation is contingent on the facts. If the code were small (say 500 lines), unvalidated, and understood by the whole team, a rewrite might be reasonable — there would be little irreplaceable value at stake. Naming the conditions under which your recommendation would flip is not weakness; it is what distinguishes analysis from dogma. Here, with 15,000 lines of validated, safety-critical, poorly-understood physics, the analysis is decisive.

Discussion Questions

1. The junior engineer says, "But modernized Fortran is still Fortran — we're stuck with an old language." How do you respond, using the "two Fortrans" idea from §1.1?
2. Suppose the regulator would accept a rewrite only after two years of parallel operation proving the new code matches the old bit-for-bit. How does that change the cost comparison?
3. What is the single most urgent task in the first month, and why does the retirement deadline make it non-negotiable?

Your Turn: Extensions

• Option A. Rewrite the recommendation for a different scenario: a 500-line, unvalidated, well-understood prototype. Show how the same framework produces a different answer.
• Option B. Draft the one-paragraph regression test plan you would put in place before touching a line of REACTOR77. What is the reference, what is the tolerance, and what counts as a failure? (Preview of Chapter 37.)
• Option C. Make the opposite case as strongly as you honestly can: write the best argument for a rewrite, then explain precisely where it breaks down for this code.

Key Takeaways

• The rewrite-or-modernize decision is driven by what is irreplaceable: validated numerics and encoded knowledge. Whatever protects those usually wins.
• "The code is ugly and slow" argues for change, not specifically for a rewrite — modernization cures the same symptoms at a fraction of the risk.
• Good technical judgment names the conditions under which the recommendation would flip. A decision that cannot be wrong under any circumstances is not analysis; it is dogma.
• Choosing a language for a rewrite by fashion (Python "for readability," Rust "for modernity") rather than by fit is how teams end up slower than the FORTRAN 77 they set out to escape.