I’ve been working in government technology for more than two decades, spending a non-trivial amount of that time modernizing legacy systems to improve how they work and the digital experiences they support. Recently, I came to a somewhat uncomfortable conclusion — I was probably doing it wrong the whole time.
Traditional legacy modernization approaches — whether done through manual coding or AI-assisted conversion — focuses almost exclusively on one thing: converting old software code into new software code. Requirements documents and architecture diagrams get created along the way, but they exist solely to support that conversion process. If these projects finish successfully (and that’s often a big “if”) the new code becomes the source of truth for how the system works.
But now, a better way is emerging.
Introducing SpecOps
Like many people working with AI coding tools, I’ve come to appreciate the powerful elegance of specification-driven development. It’s now changing how I think about legacy system modernization.
In spec-driven development, you first write a comprehensive software specification describing exactly how a system should work — think of it as an encapsulation of knowledge about the system, independent from any particular technology implementation. This approach inspired what I’m calling SpecOps: a new methodology for modernizing legacy government systems.
The name combines two proven approaches for building and managing modern software:
- Spec-driven development — focusing first on comprehensive descriptions of system behavior before code is written; and,
- GitOps — treating version-controlled representations of cloud infrastructure as the ultimate source of truth for an environment.
How SpecOps is Different
Instead of just converting old code to new code, SpecOps decouples understanding how a system works from its technical implementation. This enables policy experts and domain specialists to validate system behavior in human-readable specifications. These verified specifications then guide AI coding agents (or teams of humans, or both working together) in implementing modern software equivalents to legacy systems.
Like GitOps, specifications are version-controlled in Git repositories. When changes are needed, they’re made to the specification first, then — and only then — are they propagated to the actual implementation based on those specification details. This reverses the typical government modernization pattern. Traditionally, when changes are needed they are first made to the code with the hope of updating the system documentation sometime later. What happens in practice? Documentation inevitably falls behind, leading to the poor, incomplete, or non-existent documentation plaguing so many government legacy systems.
With SpecOps, the specification is always the authoritative source. There’s never a gap between system functionality and specification details.
Why This Matters
Even when traditional modernization succeeds in converting old code to new code, that new code becomes the foundation for a new legacy system, accumulating technical debt from day one.
Decoupling system behavior from technical implementation means governments never get stuck with decades-old legacy systems they desperately need to upgrade but don’t fully understand. The specification preserves institutional knowledge regardless of the underlying technology.
A Different Future
SpecOps represents a fundamentally new way of thinking about legacy system modernization — one enabled by advances in AI coding assistants and battle-tested approaches like GitOps. When done right, I think SpecOps could eliminate the huge, risky, mission-critical system replacements that seem endemic to government. Instead of periodic modernization crises, we can have continuous evolution of critical systems guided by expert-verified software specifications.
We’ve been doing this work the same way for decades. Advancements in AI and the new approaches being developed to use AI tools is enabling a fundamentally different approach. Now is the time to start doing things differently.
Want to learn more? I’ve published the complete SpecOps methodology, including manifesto, comparison framework, and implementation guide at spec-ops.ai. It’s designed to be shared and improved collaboratively across government agencies.
Mark Headd is a Government Technology SME at Ad Hoc. He is the former Chief Data Officer for Philadelphia, serving as one of the first municipal chief data officers in the United States. He holds a Master’s Degree in Public Administration from the Maxwell School at Syracuse University, and is a former adjunct instructor at the University of Delaware’s Institute for Public Administration. He spent 6 years with the General Service Administration’s Technology Transformation Services (TTS), serving on the leadership team for 18F and leading customer success efforts for TTS’ cloud platform, which supports over 30 critical federal agency systems.
Leave a Reply
You must be logged in to post a comment.