Argues that the F-35's $1.7 trillion lifetime cost produced a jet designed for a specific threat environment that has shifted. The aircraft is individually impressive but represents a strategic misallocation — a masterpiece built for the wrong war, optimized for contested airspace scenarios that may not define future conflicts.
Frames the F-35 as a $1.7 trillion case study in the monolith problem: a system that tries to be everything for everyone — stealth, sensor fusion, electronic warfare, ground attack, air superiority, VTOL, carrier ops — and becomes too important to cancel and too complex to fix. The three variants sharing a common airframe mirrors a shared codebase with variant-specific modifications that compound integration costs.
Highlights that the jet carries over 8 million lines of code — more than any fighter ever built — plus millions more in ground maintenance software (ALIS/ODIN). Block 4 capability upgrades are years behind schedule, and even the replacement for the maintenance system has suffered its own delays, making software the program's most persistent bottleneck rather than aerodynamics or materials.
Submitted the article highlighting how the Joint Strike Fighter mandate — one airframe serving Air Force, Navy, and Marines simultaneously — drove costs from a projected $233 billion to over $400 billion in acquisition alone. The requirement to replace three distinct aircraft (F-16, F/A-18, AV-8B) with variant-specific modifications of a shared design created compounding integration complexity.
War on the Rocks published a detailed analysis arguing that the F-35 Lightning II — the most expensive weapons program in human history at roughly $1.7 trillion in lifetime costs — is a technical masterpiece optimized for a threat environment that no longer exists. The piece landed on Hacker News with 234 points, drawing heavy engagement from the developer community. Not because developers care about fighter jets per se, but because they recognized the architecture.
The F-35 was designed as a Joint Strike Fighter: one airframe to serve the Air Force, Navy, and Marines, replacing the F-16, F/A-18, and AV-8B Harrier respectively. Three variants (F-35A, B, and C) sharing a common codebase — sorry, airframe — with variant-specific modifications. The program launched in 2001 with a projected cost of $233 billion. It is now north of $400 billion in acquisition costs alone, with per-unit costs that have only recently dipped below $80 million after decades of overruns.
The jet carries over 8 million lines of code — more than any fighter aircraft ever built — and its Autonomic Logistics Information System (ALIS), the ground-based maintenance software, adds millions more. The software has been the program's most persistent bottleneck: Block 4 capability upgrades are years behind schedule, and the replacement for ALIS (called ODIN) has itself suffered delays.
The Hacker News thread lit up not over defense policy but over a pattern every senior engineer has seen: the system that tries to be everything for everyone and becomes an unmaintainable, over-budget platform that's too important to cancel and too complex to fix.
This is the monolith problem at $1.7 trillion scale. The F-35 was designed with maximum capability density — stealth, sensor fusion, electronic warfare, ground attack, air superiority, vertical landing (B variant), carrier operations (C variant) — packed into a single platform. Each capability justified individually. The integration complexity? That was someone else's problem, deferred to the next phase.
Software engineers call this "second-system effect" (Fred Brooks) or, less charitably, "enterprise platform syndrome." You start with a reasonable scope. Stakeholders add requirements. Each addition is small relative to the whole. Nobody owns the complexity budget. By the time you realize the architecture can't absorb another feature without destabilizing three others, you've spent $400 billion and 24 years.
The maintenance story is equally familiar. The F-35 requires roughly 24 hours of maintenance per flight hour for certain variants — compared to about 10 for the F-16 it replaces. Depot-level maintenance backlogs have left mission-capable rates hovering around 55%, meaning nearly half the fleet can't fly on any given day. For a software team, that's the equivalent of a system with 55% uptime being called "production-ready."
Meanwhile, the threat landscape shifted. Ukraine demonstrated that $500 commercial drones can destroy million-dollar armored vehicles. Turkey's Bayraktar TB2 drones performed strike missions in Libya, Syria, and Nagorno-Karabakh at a fraction of the cost of manned aircraft. China is mass-producing autonomous drone swarms. The question isn't whether the F-35 can beat a drone in a dogfight — it obviously can. The question is whether it matters when your adversary can field 1,000 drones for the cost of one F-35 sortie.
This maps directly to a pattern the software industry has already lived through. The F-35 is the J2EE application server of defense: technically impressive, theoretically capable of anything, practically too expensive and complex to iterate on at the speed the environment demands.
The drone revolution mirrors the microservices shift — not because individual drones are superior to manned fighters (they aren't), but because they change the economics of failure. A $50,000 drone that gets shot down is a rounding error. An $80 million jet that gets shot down is a national crisis. This is the same logic that drove the move from monolithic deployments to containerized services: not that each container is more capable, but that failure becomes cheap, recovery becomes fast, and you can iterate without risking the whole system.
The biological parallel is even more instructive. Evolution doesn't produce F-35s. It produces swarms — ant colonies, immune system T-cells, schools of fish. Nature solved the complex adversarial environment problem millions of years ago: not with one perfect organism, but with many disposable, loosely coordinated agents that are individually expendable and collectively resilient. The Pentagon is slowly learning what evolutionary biology (and distributed systems engineers) already knew.
The Collaborative Combat Aircraft (CCA) program — autonomous drones designed to fly alongside manned fighters — is the Department of Defense's belated acknowledgment of this. It's essentially a sidecar architecture bolted onto the monolith. If that sounds like a familiar migration strategy, it should.
The F-35 story isn't really about jets. It's about what happens when you let capability accretion drive architecture instead of the other way around.
If you're building a platform that serves multiple stakeholder groups with divergent requirements — and you're resolving every conflict by adding abstraction layers rather than saying no — you're building an F-35. The warning signs are identical: ballooning integration test suites, maintenance costs that grow faster than feature delivery, and a codebase where every change requires sign-off from six teams because everything is coupled to everything.
The actionable takeaway: budget for complexity the way you budget for compute. Every feature has a sticker price (development cost) and a carrying cost (maintenance, cognitive load, coupling). The F-35 program meticulously tracked the sticker price and systematically ignored the carrying cost. Most software projects do the same thing. The teams that avoid this failure mode are the ones that treat simplicity as a feature with its own line item, not a nice-to-have that loses every prioritization fight.
The second lesson is about disposability. The most resilient systems aren't the ones with the most capable individual components — they're the ones where components can fail and be replaced without cascading consequences. Design for replacement, not for permanence.
The F-35 will fly for decades — it's too embedded to replace, too expensive to duplicate, and too politically distributed across 35,000 suppliers in 45 states to cancel. Sound familiar? The best monoliths don't die; they get surrounded by smaller, faster systems that handle the new workloads while the monolith handles the legacy ones. That's exactly where defense acquisition is heading, and it's exactly where your aging platform probably is too. The question isn't whether to strangle the monolith. It's whether you start now or wait until the drones — or your competitors' microservices — are already overhead.
I see what the author is saying and I agree to some extent, but I think the F35 is mostly irrelevant in terms of the argument being made. I think it is needed and does it's job as a deterrent. The F35 means that that no one can really control the skies against the US. Iran was considered to hav
So none of them lost on ground in Iran.No US ship was to my knowledge even hit by a drone/missle.Iran has been prepping forever for this with Russian/Chinese equipment.This sounds identical to previous arguments I saw of how hard it would be for US to beat Iran in open conflict. China is d
Somewhat ridiculous piece. Ukraine, 4 years after, still operates a significant number of jets it entered the war with. This is despite hundreds of attempts to eliminate them on the ground with airstrikes, drones, cruise and ballistic missiles.And naturally F-35s on that theatre would have been a ga
It concerns me how casual the article and some of the comments here discuss an actual war against China, as if that were a reasonable scenario.Of course I understand wanting to be prepared even for grim scenarios such as these. Military strategists should of course continually be refining such plans
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
> Meanwhile, modern conflict, from Ukraine’s drone war to naval engagements in the Red Sea to Iran’s own mass missile and drone salvos, increasingly favors systems that can be produced at scale and replaced when lost. The F-35 is a masterpiece. But a force designed around a masterpiece is not des