The ongoing debate over the sequester has gotten me thinking of software design. Some in the United States military have argued that the next war we need to prepare for is a small war in the Middle East, others a massive naval conflict with China. Failing to prepare for either would be disastrous, and so our military budget must forever expand as we prepare for both. Given the perceived threat environment, I can understand why the Pentagon is yelping so much at some relatively mild trims to their planned budgets. Yes, the sequester cuts are poorly planned and will incur financial/operational costs in terms of sudden contract disruptions – but the real reason the Pentagon is complaining is that they want this money in order to prepare for both these threat environments. Plus Iran, and rapid humanitarian deployments, and pirates off Somalia, and God knows what else.
Here’s a provocative counterargument for the Pentagon – stop trying to plan for the next war, because we know you’ll get it wrong. That’s okay – you’re only human. Everyone always gets the plan for the next war wrong. That doesn’t mean you have to stop running simulations and wargames – though sorry, our enemies will always come up with something we didn’t think of. Again – they always do. But stop trying to plan for the next war or any war because preparing for everything is impossible. Instead of preparing for everything, prepare for anything.
Preparing for anything means a priority on building a flexible infrastructure for response. The US’s greatest military challenges have been the Civil War and World War II, and we triumphed in both because we had the material and human infrastructure to develop appropriate responses to the threat environment and scale the responses really big, really quickly. It’s hard to know what exactly that means in the modern context – that’s the real utility of running those wargames, in the hopes that across all the scenarios some common patterns start to emerge. We’ll get it wrong, as we always do. But by prioritizing flexibility over optimization we’re less likely to be disastrously wrong.
A parable from World War II – the T-34 versus the Tiger tank. The Tiger was a massive piece of wonderful German engineering: the most armor, the most powerful engine, the most destructive main gun. The T-34 was much smaller, and in a confrontation the Tiger would win every time. Not even 1-on-1 – there are documented engagements where a single Tiger would wipe out 20+ T-34s without taking a scratch. Within the engagement, the Tiger was the unquestioned superior solution. Yet the Tiger never made a dent in the course of the larger war, and the T-34 is regarded as the highest achievement in tank design in the history of warfare. Why?
The T-34 was spectacularly well-suited to the actual problem at hand, whereas the Tiger was incredibly poorly suited. The powerful engine of the Tiger was precision-made by hand, limiting production speed and capacity enormously. It was also unreliable – and since there were so few Tigers and parts were handmade, parts were pretty darn scarce too. The T-34’s engine wasn’t built for raw power, it was built for reliability. Oh, and it was “precision-engineered” too – Soviet engineers worked tirelessly in order to reduce the number of parts and decrease the precision of machining required. In the tough conditions of a Russian winter guess which one was the dominant approach? Speaking of, there weren’t much in the way of roads out there. Well, having the best damn tank in the world doesn’t do you any good when it’s so heavy it sinks instantly in soft ground and breaks 90% of the bridges out there. The Germans built for the dominant solution, and the Russians built for the one useful in the most contexts.
I’m speaking in software terms here because they’re extremely relevant. We’ve all encountered the over-engineered solution many times. For any given mathematical task there are many solutions that provide the dominant solution for the problem you want to tackle right now. But if you asked everyone who uses numbers in their work the one program they couldn’t live without, it’s Microsoft Excel. Imagine a map of America where Excel sits in the middle of Kansas and your desired use case may sit anywhere on the map. Other solutions may be closer to your particular use case, but Excel has the shortest average distance to the destination.
This is just a long-ass way of saying that when the military tries to simultaneously prepare for a war in China with fancy stealth fighters and a war in the Middle East with COIN tactics, it basically guarantees building itself a Tiger. Procurement budgets with unlimited money want to look for the dominant solution to every single use case, and build themselves the ultimate versatile toolbox with a million purpose-built tools. To mix terms from two worlds, we don’t get to define our own use case – the enemy does. If we assume that we’ll be wrong about the use cases that we face, it shows us that the “build many Tigers” approach doesn’t guarantee failure, but it guarantees a lot of wasted money and a strong possibility of failure.
Not all is lost, however – there is one way to guarantee we’ll be less wrong, which is to lessen the universe of potential use cases. The relevant area here is political, not technological – the more America tries to do all things in all places, the larger the universe of things we can screw up in our preparation and the more wildly wrong we can be.