The Other National Debt: Uncle Sam’s Trillions in Technological IOUs

From databases old enough to collect social security checks to billion-dollar projects stuck in development hell, it’s worse than we think—and it matters more to taxpayers than ever. 

For decades now, America’s technical infrastructure has been a story of two separate worlds. On one hand, our private sector is a global envy and a key driver of US economic dominance. There are 1,500+ tech startups worth over a billion dollars today, roughly half of which are American. Yet there’s also a shadow realm, where the world’s richest country runs its government on tech stacks that are staggeringly outdated, brittle, and expensive.

Just how bad is it? How did we get here? And how can we turn it around? 

1. Why this matters

Whatever a government’s policy agenda, its implementation runs through software. When core government software is rigid, patchwork, and stuck in time, so is government policy.

For a great primer on this dynamic, we highly recommend Jennifer Pahlka’s Recoding America, which recounts her experience helping to spin up the US Digital Service following the healthcare.gov website fiasco. Her core finding: digital competence and effective policy are tightly linked, and both need fixing. If governments don’t improve at developing and buying software, their ability to deliver cost-effective services can’t improve either.

The upshot: attacking America’s financial debt crisis means tackling its technical debt too.

What is technical debt in layman’s terms?

It’s the rough equivalent of how much of your budget goes to debt repayment instead of new investments. The US federal government currently spends over $100 billion per year on total IT investments, some 80% of which goes to maintaining and operating outdated infrastructure. But this is only part of the true cost. Bad software is toxic for staff and citizen morale, necessitates overstaffing, and leaves systems vulnerable to costly fraud, outages, and hacks. When you factor in state and local governments, opportunity costs, and the dampening effect this debt has on GDP growth, the total drag on the US economy is somewhere in the low trillions per decade.

2. Our dark status quo

The US Department of Defense has famously failed every audit since attempts restarted back in 2018. Why? 

Quoting page 259 of Recoding America:

...the Department of Defense has 161 different accounting systems. As of 2011, the department had 2,258 separate business systems, including 709 just for human resource management and 335 more for financial management.

But the problem is deeper than just bloat. Many of the bedrock systems powering the daily operations of the federal government were built in the 1950s. The same is also true at the state level. We saw the fruit of this during the pandemic, when months-long emergency hackathons were required just to issue stimulus checks and extra unemployment benefits. And fraud was rampant across these programs. Too many systems were working in isolation, unable to adapt and unable to talk to other databases that held useful data. 

It’s not just that the status quo leaves governments flatfooted in the face of crises or that needful digital collaboration between agencies is often between slow and impossible. It’s that we’re also imposing a tax onto citizens when they need their government most:

Today, Americans spend 10.5 billion hours a year—about forty-two hours per adult—on paperwork just for the federal government. - pg. 142 

This has a cumulative effect on citizens. One moment they’re using commercial software carefully designed to be accessible and friction-free, and the next they’re time-warped into the digital equivalent of a dusty DMV office. They notice the difference. One works, the other doesn’t. Why are they paying taxes and not easily getting the services promised? 

Are there any successful examples of US government software projects?

Yes! The US Digital Service (now the US DOGE Service) and its sister agency 18F did excellent work both advocating for fundamental changes and leading the charge on several big software projects like login.gov. This has opened the door for more collaboration with Silicon Valley, which we cover more in origin story here.

3. How we got here

The first great sin in software development is designing from the top down instead of working backwards from how users actually interact with your product. The longer you spend drafting complex requirements, the less responsive you’ll be to what really works.

Even so, the default government playbook for the past few decades has been:

1. Starting with requirements, mostly defined by bureaucratic teams that neither talk to each other nor have any expertise in building software that anyone loves.
   

2. Asking vendors to build or retrofit software that meets these requirements precisely, leaving little room for new tools and architectures, future flexibility, or interoperability.
   

3. Multiple delays and cost overruns later, delivering this software to constituents and only then finding out if it meets their needs or interaction patterns effectively.
   

4. Bringing these concerns back to the vendors, who are happy to adjust contingent on new deadlines and budgets, but who won't challenge the core underlying issues.
   

5. Finding out that legislators and regulators have updated their requirements, at least partially restarting the whole cycle.

The second great sin in software development is slowness. When software is the product of glacial bureaucratic processes and multi-year development contracts, there’s little room left for iteration and responsiveness to what users really want from the service.

The results have been as expected:

• Requirements are often so byzantine that only legacy vendors can understand them, reinforcing their stranglehold. They have almost no incentives to stop the cycle, and very strong incentives to lobby for new laws and rules that entrench their positions.
  

• Most systems have become like Kowloon Walled City, where new layers of software are built atop the bedrock mainframes with little thought to harmony or structural integrity.
  

• These systems are still sprawling in silos, requiring even more new software to be commissioned just to create bare minimums of interoperability.

How can we fix this? We explore this in How to Build Government Software That Taxpayers Actually Like.

Aren't you just another software vendor talking your own book?

Yes and no! It's easy (and expected!) for new entrants to criticize incumbents and sell a vision of how everything will be faster, better, and more cost-effective if you just pick them. While talk is cheap, our answer is that we have a different business model built around different incentives. While we have a longer explanation here, the gist is that we focus on reusable software. This means we make more money if what we deliver delights buyers enough that they endorse us to other departments and agencies to buy their own versions of the same code. But you keep a full copy too, with no licenses, royalties, or lock-in. While we can offer long-term support, we'd prefer to foster internal ownership. We just want public services to work. If they do and vendors become irrelevant, we'll happily just return to focusing on private sector projects.