The Perverse Incentives of Government Software Contracts
Government software development is one of the strangest corners of the tech world. On paper, it’s about building reliable, mission-critical systems to serve millions. In practice, it often rewards inefficiency and punishes quality. Years ago, during my time at the Naval Postgraduate School, I wrote a tongue-in-cheek paper titled “There is a Lot of Money to be Made Writing Bad Software for the Federal Government.” Unfortunately, the title wasn’t just a joke—it was an observation backed by experience.
The problem starts with how contracts are awarded. Most major government software projects operate under a “cost plus” model, where companies bid based on projected costs plus a profit margin. Theoretically, this should encourage competitive pricing. But in reality, it incentivizes lowballing upfront costs, often with no real plan to hit those targets. The result? Contractors rush to meet deadlines, cut corners, and deliver barely passable code—just enough to check the boxes in a bloated requirements document.
When that first iteration inevitably fails to meet expectations, the government is left scrambling. And who’s the most “qualified” to fix the broken system? Ironically, the same contractor who built it in the first place. This cycle can repeat itself multiple times, and each round brings in more money for the original vendor—essentially rewarding failure. It’s a frustrating loop that rarely produces excellent outcomes, even though it frequently generates massive invoices.
In fairness, government systems are often daunting in scale and complexity. But the core issue lies in misaligned incentives. Excellence isn’t rewarded—persistence through mediocrity is. So when I heard about Elon Musk’s DOGE team planning to rewrite Social Security’s COBOL-based system in a few short months, I couldn’t help but smirk. That’s not how this game works. Not even close.