it was still running! It was still running its tests and passing! So. . .we absolutely do value making a quality product.
From the perspective of military manufacturers, more money is paid for what they do because they invest additional resources in producing durable, military-grade products—i.e., things that will resist falling into transience and disuse. In fact, many of those I spoke with seemed proud of the fact that military equipment remained usable for generations. It was as if the reliability of products, proved through testing, reaffirmed the reliability of the engineers and managers tasked with designing them. They were proud of what they had done, in other words, precisely because they could see how waste, as inevitable entropic decline, had been anticipated and avoided. Taking satisfaction in one’s work often meant defeating waste.16
In a way that might seem paradoxical, these discussions of prized durability were never far from examples of failure and obsolescence. Rather than treating durability and transience as opposing qualities, engineers connected them as the product of one’s labor and the background conditions against which one struggles, respectively. Insuring quality meant careful attention to every product’s slow descent into waste and worthlessness, formally assessed as mean time before failure (MTBF). This required extensive testing, as Simon explained:
Every single piece of equipment on the helicopter and all of its support equipment is analyzed by logistics to mean time to failure. So we know that of a thousand pieces for five hundred helicopters so many are gonna fail per year, so that’s how many you keep in the spare parts inventory. And it’s just failure—they’re in the ocean, salt water is spraying on them, could be in the Arctic, very adverse circumstances.
The Seahawk helicopter that Simon worked the most on was intended for the Navy for purposes of doing search and rescue. And this could include the open water or downed pilots in Afghanistan, where all components needed to work to guarantee both safety and mission success (and, by extension, the presumed public goods associated with military strength).
People have been building these parts for fifty years, similar parts. And you do stress tests: for every part it has to go through an air-worthiness test and an environmental test. Environmental test puts it through cycles of heat and cold and banging around and dropping and being exploded.
This is still about preserving customer ties. According to Simon, the DoD representatives “either witness the tests or see the results.” When the Seahawk was in development the Navy sent its own engineers, mostly former pilots: “There would be all these very strong tests. Plus you would have the history of very similar built equipment, and they would all be built to military specification standards. Some of them are very old.”
Tests during product design and development also include models for the eventual breakdown of military products. As Simon pointed out, this means:
Life cycle. . .cost analysis. . .including disposition of all parts and of the military craft itself. . .decommissioned and everything. . . Typically you do a war game and you say how many are to be destroyed in battle, how many are left on the battlefield, after twenty or thirty years of useful life, how many have to be decommissioned, and the costs for that, and the expected disposal and reuse. All that’s calculated for every military program. . . Typically you end up using the Army or the Air Force or the Navy [method of life cycle analysis] but you still gotta use your company’s, so I’m familiar with Lockheed Martin where they have what they call logistics. . . . Analysis of every part and every military aircraft or ship or whatever and they’ll say over the twenty-five-year life you need to have so many spare parts stored in the US, near the battlefield, close to the battlefield, so that they can be taken care of during battle and during battle damage and during normal wear and tear. . .and then they do a disposal cost for each one of those.
In other words, every product’s inevitable entropic decline into waste is incorporated into its design and sale to the DoD. Like neurotic subjects who seek out that which fills them with dread, Lockheed personnel keep waste in abeyance and carefully account for it. When accused of being “wasteful” by presidents, Marxists, or anthropologists, this is what industry engineers will be quick to point out. They are not disappointed or dispirited by the descent of even the most durable of products into disuse, as far I could detect, because they spend a great deal of energy imagining such failures and planning for them.
Bork balked at the notion that the production process might be wasteful. For him, as for many engineers, “waste” meant wasted time and effort. They associated it with products that did not work, that failed or broke down, and served no purpose for the customer. This is precisely what they tried to avoid through good customer relations and extensive product testing and design. The primary goal of production was to reduce such waste, both in the product produced and in the production process itself:
Whenever something fails, the first person that gets called is the software engineer to explain what the failure is, and why it failed. And I still do that today, I get calls, “We got a failure in the lab, can you explain what this is?”. . . We’ve got one group that does all sorts of testing, so that’s the diagnostics group, that’s the group I’m in. And so, when we’re doing these environmental tests, we’re the ones that write the tests and then interpret the failures. . .writing software that tells you why it failed is much more expensive than writing software that tells you, “It failed.”
The former is known as mean time before failure (or MTBF) in engineering parlance. Knowing that something failed, that it is not meeting criteria promised to the client, is not enough to ensure that it does not fail again. One must know why, and for this the interviewee offered two options: either they, the software engineers, are called upon to explain why something fails, or a “more expensive” form of software is developed to tell them why. This means that their efforts on behalf of a better product avoid waste in two senses. First, a product that might otherwise turn out to be waste is engineered to last (that is, to function with a more acceptable MTBF). Second, there is a savings implied when an engineer does the work that expensive software might otherwise have to do. The value of the product is saved, and the company—and potentially the client—save money.
The military and manufacturers also employ additional analysis of their products to maximize utility and minimize waste. At the same time, the pursuit of quality could itself be regarded as wasteful if it meant being noncompetitive. IBM had a reputation for perfectionism going back many years. According to Bork:
IBM had a big stick up its butt for the longest time. They always had this Thomas Watson Calvinist engineering approach. You could even see that in the tail end of the IBM commercial products. Before they got out of their desktop PC. Their equipment was always overdesigned and overbuilt, I mean you could drive a car over them and barely dent it. It was the corporate culture, was one of exacting quality. To a point of not being competitive. If you were getting some knockoff place in Taiwan making cheap PCs, how can you compete with that?
The cost of “overbuilding” products was not just a loss in corporate profit, but could be seen everywhere in the community, where global competition (with Taiwan for instance) is blamed for loss of jobs and local decline more broadly. Sometimes creating a quality product could waste time and resources as manufacturers encountered technical problems. Louis said that the DCMA regularly encountered this phenomenon:
You can also have technical problems come out in the course of development work. And I’ve seen where the contractors will come back to the military and say, “You know, we don’t have a really good fix for this. We can’t do what you want to do. We really need to. . .” what’s called rescope, that is, change the scope of requirements: “These things that you’ve asked us to do, we cannot do. We need to delete them or substitute other things.”
“Rescoping” is also known as “requirements turn,” since it involves modifying the requirements as one develops a product, which can lead to dramatic scheduling
