Book Review: The SpecOps Method
Government is sitting on a ticking time bomb—and it’s not the national debt.
It’s the millions of lines of COBOL running unemployment systems, tax processing, and benefits eligibility. Code written in the 1970s by people who are now in their 70s. And those people? They’re retiring at a rate of 10,000 Baby Boomers per day.
Mark Headd’s The SpecOps Method isn’t just another book about modernizing legacy systems. It’s a survival manual for the coming knowledge extinction event.
The Core Insight
DO NOT translate old code. Capture knowledge.
The traditional approach: point AI at COBOL, ask for Java, ship it, celebrate. Six months later you discover the new system has been miscalculating benefits for edge cases because the AI faithfully translated a bug that’s been in production since Reagan was president.
SpecOps flips this. Before writing a single line of modern code, you extract specifications—human-readable descriptions of what the system does. Then you have domain experts verify those specifications. Only then do you implement.
The specification becomes the source of truth. Not the legacy code. Not the new implementation. The spec.
Why This Matters Right Now
I’ve spent my career building technology companies. I’ve watched American institutions assume their technical lead was permanent. It’s not.
The federal workforce is older than it’s ever been. In 2025 alone, approximately 317,000 federal employees left—double the typical rate. Over 30% of IRS CIO staff departed by mid-year. Current employees describe systems breaking and taking days to fix “because no one is left who knows how.”
This isn’t a future problem. It’s a right-now problem.
Headd worked at 18F. He’s seen the inside of government technology. He’s watched modernization projects fail—Canada’s Phoenix Payroll disaster, the VA EHR debacle, California DMV’s $185M abandoned project. He understands why.
The Six Phases
SpecOps is structured and methodical. Six phases:
- Discovery & Assessment — Map the system, identify who knows what, create a “knowledge map” of expertise that’s about to walk out the door
- Specification Generation — AI analyzes legacy code and produces draft specifications in human-readable terms
- Specification Verification — THE PIVOTAL PHASE. Domain experts review and correct the specs before any implementation
- Modern Implementation — Generate new code from verified specifications
- Testing & Validation — Test against the spec, not just legacy behavior
- Deployment & Knowledge Transfer — Ship it incrementally, archive the knowledge
The third phase is where SpecOps diverges from everything else. Direct translation skips verification entirely—there’s nothing for humans to verify except “does the new code match the old code?” Which perpetuates bugs and misses policy drift.
SpecOps inserts a verification checkpoint that domain experts can actually engage with. A 30-year policy analyst can’t read COBOL. She can read a specification that says “income shall be calculated by averaging actual earnings across the employment period” and immediately know that’s wrong for seasonal workers.
The Team A vs Team B Story
Headd tells a parable that crystallizes the methodology:
Team A uses AI to translate COBOL to Java directly. Code compiles. Tests pass. They ship. Six months later they discover miscalculated benefits for edge cases—a bug the AI faithfully translated from legacy code.
Team B generates specifications first. A policy analyst reviews them. She spots the seasonal employment flaw *immediately*—in plain English, not code. It’s corrected before implementation begins. The modern system is correct from day one.
The difference? A verification step in terms humans can understand.
Relation to The Phoenix Architecture
The Phoenix Architecture concept—treating code as disposable and periodically burning it down for fresh implementations—actually dovetails perfectly with SpecOps.
cccccbvnnhthtrbjlcnekffbbkdnvvdulihkrdfhvvbd
Here's the connection: if the specification is your source of truth (not the code), then the code becomes genuinely expendable. You can regenerate implementations whenever you want—new language, new framework, new architecture—because the knowledge lives in the verified spec, not in the codebase.
Traditional Phoenix approaches are risky because you're destroying institutional knowledge every time you rebuild. But with a SpecOps-verified specification in hand, "burn it down and rebuild" becomes safe. The spec survives the fire. You could implement in Java today, decide Go makes more sense next year, and regenerate from the same verified specification. The domain experts already validated that the spec is correct—you don't need to re-verify just because you changed languages.
This is what Headd means when he says the specification "persists after deployment" and "survives regardless of what happens to the code." SpecOps essentially enables Phoenix Architecture by decoupling knowledge preservation from code preservation.
What I Liked
The urgency is palpable. This isn’t academic. Headd makes clear that the window is closing. Every month that passes, more institutional knowledge walks out the door.
The methodology is practical. He doesn’t require exotic tooling. Git, an AI coding agent (Claude, Copilot, Cursor), markdown, and a pull request workflow. Start tomorrow.
The scope is right. SpecOps isn’t just for government. It applies anywhere legacy systems run with aging expertise: healthcare, finance, insurance. The methodology generalizes.
The principles are clear. Six principles that stick:
- Specification is the source of truth
- Knowledge preservation precedes code translation
- Domain experts are arbiters of correctness
- AI assists, humans verify
- Changes flow through specifications
- Specifications should be accessible
What Could Improve
The book is light on case studies. More real-world examples—names, systems, outcomes—would make it more compelling. I wanted war stories.
The tooling section could go deeper. What instruction sets work for COBOL specifically? How do you structure specs for complex rule engines? More templates and examples would help teams get started faster.
And while Headd acknowledges SpecOps isn’t limited to government, the book is government-focused throughout. A few private-sector examples would broaden the appeal.
The Bottom Line
Here’s the uncomfortable truth: we’re racing against a demographic clock.
The people who understand legacy systems are retiring. The systems themselves are becoming unmaintainable. Traditional modernization approaches don’t preserve knowledge—they just swap one black box for another.
SpecOps offers a different path. Extract knowledge into specifications. Verify them with domain experts. Implement from verified specs. Preserve institutional understanding as a first-class concern.
Is it more work upfront? Yes. Does it slow down the initial sprint? Yes. Does it result in systems that actually work correctly and knowledge that survives the modernization? Also yes.
If you’re responsible for legacy systems—in government or anywhere else—read this book. Then start small. Pick one component. Run it through the six phases. See what emerges.
The window is still open. But it’s getting narrower.
“Every specification verified is knowledge preserved. Every team that demonstrates success creates evidence that builds momentum for broader adoption.” — Mark Headd
Rating: 4⁄5 — Essential reading for anyone managing legacy systems. Would be 5⁄5 with more case studies and implementation examples.
