The military procurement process is famously bad, and it’s easy to come up with stories of the US government overpaying for whatever the item du jour is. I’ll be the first to admit that the DoD has serious issues, and that the system is far from perfect. But the military is also a very demanding customer. For instance, if a piece of software on your computer crashes, the consequences are likely to be fairly minimal. If a piece of military software crashes at the wrong time, people are likely to die. Here’s a tale of one tiny piece of the development of some of that software. Everything included is true, although some details have been obfuscated.
It was decided that a Large Military Airplane (LMA) needed a moving map. After some analysis, it was decided to develop it from the moving map software already in use on a Small Military Airplane (SMA). Everyone involved thought the software was fairly close to the requirements, and merrily set to work.
Several months later, someone noticed a problem. The LMA was tasked as part of the response force in case the Nazis in Antarctica started making trouble again, and that meant the moving map had to be able to function near the poles. The SMA was shorter-ranged and didn’t have to worry about that. So the people who had written the moving map had used the sinusoidal projection, which was computationally easy and perfectly adequate at the latitudes the SMA operated at.1 But for attacking the Nazi bases, the distortion would be too severe to tolerate.
The Sinusoidal Projection
This caused great consternation. The LMA had to be able to support operations against the Nazis, but redoing the map projection wasn’t included in the plan. Would it delay the project? Would the LMA crew have to resort to map and compass for the next punitive expedition down south? Eventually, the programmers found a way to modify the system to use the orthographic projection without too much delay, and the day was saved. (For everyone except Hitler’s clone and his henchmen, that is.)
The Orthographic Projection2
This is just one example of a large and complex problem. In hindsight, it’s easy to say that this was an obvious problem they should have caught earlier, but there are dozens of such potential issues in even a relatively simple project like giving the LMA a moving map. If it wasn’t the projection, it would have been something else, some feature that was predicted to be easy before the software team got a close look at it and realized it would take ten times as long as predicted. Everyone involved was dedicated and worked hard, but there are so many potential problems that some of them will slip through.
A lot of military procurement stories are like this. The famous expensive hammer was actually a non-sparking non-magnetic model.3 The expensive toilet seat was a custom toilet tank cover for an airplane.4 This isn't to deny the existence of boondoggles,5 but much of the reason that military procurement looks so expensive and inefficient is that military applications are very tricky compared to those faced in the consumer world.
1 For the pedants, the central meridian of the sinusoidal projection was always set to the longitude of the center of the displayed map. ⇑
2 To be clear, you can project the orthographic at any point on Earth's surface. This one happens to be centered at the South Pole, but the moving map used the screen center. ⇑
3 I've also heard that it was a result of accounting rules assigning overhead equally across all parts in an order which included the hammer and a bunch of expensive stuff. Either way, they weren't getting grossly overcharged. ⇑
4 At a former job, I worked on airliners, and I saw several $1000 bolts there. In my (admittedly limited) experience, the military probably does no worse than the airlines on this front. ⇑
5 There are also serious problems worldwide in terms of deciding on the right systems to buy, but that's a topic for another day. ⇑
Comments
I think the problems the military faces are less to do with the actual engineering level decisions, but rather at the higher level of setting the specs/strategic use, as well as a bit of excessive optimism on the jack of all trades front.
To the first point, the LCS idea seems sort of reasonable, but in practice they seem to be sort of why bother ships that don't have useful capabilities. Similarly, the A400M (admittedly a European project, so not US DoD) is an amazing piece of engineering in some respects, but the size of it means that it can no longer carry its original cargo, because the cargo has grown, which in some sense makes it obsolete before it even enters service.
To the second point, the F-35 seems like a very expensive way to half fulfill a lot of missions, rather than building simpler airframes that more closely meet the needs of the various services, and then incrementing from there. I think of you look at past attempts to have tri-service aircraft, like the F-111, they end up working reasonably well for one service, but not as well in other applications. The F-4, on the other hand, was built as an optimized naval fighter from the first, and as a result of that design clarity was able to succeed in non naval roles.
I get that there are huge training and logistics costs associated with having multiple types, rather than going to one or two major airframes, but at least for the US I think the overall force is large enough to sustain multiple types without too much loss in efficiency. Furthermore, the costs to sustain the various types seems more amenable to attack than the inevitable difficulties and delays of designing and building a multi service aircraft.
If I was head of procurement, I would push for more projects, but make them each more specialized and somewhat less ambitious in terms of scope. (I think technological innovation is something more of an open question, in that you want your equipment to have the latest tech, but at the same time some things could probably have dealt with a few more years in the incubator, rather than being pushed to production.)
And yes, I know the F-35 does better than half fulfill most of its missions, but it still seems like they're trying to shoehorn a lot of missions into one airframe that's not ideally sued for any of them.
That's a good way of putting it. This post was intended more as a quick "here's an example of the sort of stuff that goes on at the nuts and bolts level of procurement" than a defense of some of the worst high-level programs. I should talk about those, but that's an issue for another day.
I'm definitely with you on reducing joint programs and trying to go back to the service-specific procurement model. I've usually used the exact same examples, actually.
That said, I'm not sure it would help that much with the F-35 in particular. A great deal of the cost and delay there has been from the software side, because it's getting a level of systems integration previously unknown in aircraft. And it's going to be really potent when they get it working. But even if we'd bought three different airframes, they'd all be using the same software, which would be having the same problems. And there's a part of me which is afraid that in that case, there would be pressure to cut it because it's really hard to explain why it's so important. As part of the JSF program, it's harder to get rid of. On the other hand, I don't really think that it was a deliberate choice in view of that to seek a common airframe.
You just wanted to show the picture of the SeaMonster. I do think it is a rather cool airplane with no valid reason for existence.
I won't say my fondness for weird old airplanes didn't play a big part in using that picture. Also, it was different enough from any possible real LMA that it seemed safe to use. It did have a valid reason, though. The idea was to have a heavy coastal bomber/minelayer, but it got cancelled because of Polaris, like so many other cool projects.
...Your account of the moving map story reminded me of the semi-legendary story (and TRUE) about some modified simulator software used by the Australian Army for their helicopter gunships. From snopes.com:
"The reuse of some object-oriented code has caused tactical headaches for Australia’s armed forces. As virtual reality simulators assume larger roles in helicopter combat training , programmers have gone to great lengths to increase the realism of the their scenarios, including detailed landscapes and — in the case of the Northern Territory’s Operation Phoenix — herds of kangaroos (since groups of disturbed animals might well give away a helicopters position).
The head of the Defense Science and Technology Organization’s Land Operations/Simulations division reportedly instructed developers to model the local marsupials’ movements and reaction to helicopters.
Being efficient programmers, they just re-appropriated some code originally used to model infantry detachments reactions under the same stimuli, changed the mapped icon from a soldier to a kangaroo, and increased the figures’ speed of movement.
Eager to demonstrate their flying skills for some visiting American pilots, the hotshot Aussies “buzzed” the virtual kangaroos in low flight during a simulation. The kangaroos scattered, as predicted, and the Americans nodded appreciatively . . . and then did a double-take as the kangaroos reappeared from behind a hill and launched a barrage of stinger missiles at the hapless helicopter. (Apparently the programmers had forgotten the remove “that” part of the infantry coding).
The lesson? Objects are defined with certain attributes, and any new object defined in terms of the old one inherits all the attributes. The embarrassed programmers had learned to be careful when reusing object-oriented code, and the Yanks left with the utmost respect for the Australian wildlife.
Simulator supervisors report that pilots from that point onwards have strictly avoided kangaroos, just as they were meant to."
The actual story is not quite what happened:
"As revealed by Dr. Anne-Marie Grisogono, head of the Simulation Land Operations Division at the Australian DSTO (Defence Science and Technology Organisation) in the publication Defence Systems Daily, she did not “instruct developers to model the
local marsupials’ movements and reaction to helicopters” because “groups of disturbed animals might well give away a helicopter’s position,” nor did corner-cutting programmers seek to save some effort by simply replacing images of soldiers with images of kangaroos without modifying the underlying instructions for their behavior. Programmers did add animated kangaroos to the simulation, and they did accomplish this by replacing the visual representation of soldiers with visual representations of the hopping marsupials (while neglecting to remove the weapons and firing behavior from these representations), but this was all done out of fun (not necessity), and this humorous glitch was discovered right away and not unwittingly (and embarrassingly) displayed to a group of visitors (American or otherwise). Additionally, as Dr. Grisogono related, “[S]ince we were not at that stage interested in weapons, we had not set any weapon or projectile types, so what the kangaroos fired at us was in fact the default object for the simulation, which happened to be large multicoloured beachballs.”
The overall lesson, however - be it involving maps, Stingers, or beachballs - applies.