How the Pentagon's 1993 "Last Supper" Poisoned Engineering Software

In 1993, Defense Secretary Bill Perry gathered executives from 51 defense contractors at the Pentagon for a meeting known as "The Last Supper". His message: consolidate or die. The Pentagon couldn't sustain wartime spending levels during peacetime but needed to preserve industrial capability and infrastructure for the next conflict.

By 1997, 51 primes became five mega-corporations: Lockheed Martin, Boeing, Northrop Grumman, Raytheon, and General Dynamics. But this meeting didn't just reshape the defense industrial base. It inadvertently poisoned the incentives for engineering software - effects that have atrophied engineering teams for thirty years. These newly-consolidated primes optimized for documentation, explicit handoffs, and compliance. As expected, technical innovation was no longer a driving incentive for engineering software.

The primes that did survive weren't necessarily the fastest or most innovative – they were the ones best at navigating bureaucracy, managing risk through serialization, and documenting every decision. To be clear, this wasn't malicious. When managing multibillion-dollar programs with Congressional oversight, you optimize for documenting compliance, not developmental velocity.

When Lockheed merged with Martin Marietta, or when Boeing absorbed McDonnell Douglas, they needed software that enforced handoffs between thousands of engineers across dozens of sites. Capital Harness, Zuken, and their siblings emerged from this environment: tools to manage complexity through audit trails, approval workflows, and procedural compliance, but not inherently built to accelerate integrated systems development.

This structure broke in the mid-2010s: SpaceX started designing, building, and landing rockets. And since then, other companies like Anduril, Rocket Lab, and Hermeus proved you can build complex integrated systems with small teams moving at insane speeds. The secret is cultural and structural: responsible engineers owning end-to-end systems, deep integration from day one, and tools that accelerate decisions rather than just document them (e.g. SpaceX's internal tools like WarpDrive or Architect).

This is a fundamentally different systems engineering philosophy: when you're testing on the launchpad/tarmac and determine your wire gauge is wrong, you're updating the design, rerunning analysis, and validating the fix immediately - not navigating bureaucratic tools to document the problem rather than fix it. In this new world, the software catalyzes iteration rather than fights against it.

Today, the defense primes are trying to adopt "SpaceX speed" while running the old enterprise tools - and wondering why it's not working. The tools were built for the wrong objective function. Capital Harness isn't inherently bad software – it's extremely good at what it was designed to do, which is manage large teams working on slowly-evolving systems with extensive contractual oversight. But the "old guard" tools reward procedure-following. You check boxes, and it feels productive because everything is "green". But when first integration finally happens, the failures are late, expensive, and politically existential.

This isn't the future. The future is small teams with deep interdisciplinary ownership who build integrated systems on aggressive timelines. The future is engineers who are responsible for system-level outcomes, not just their siloed requirement. This new world of hardware development requires fundamentally different tools built around rapid integration, real-time cross-discipline visibility, and lightweight decision-making.

The 1993 Last Supper solved one problem but created another. It's time for new software built for the engineering culture that actually delivers impossible things on impossible timelines.