Military Waste. Joshua O. Reno

Читать онлайн книгу.

Military Waste - Joshua O. Reno


Скачать книгу
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 and cost changes. Unlike mission creep, rescoping involves manufacturers having to admit to the client that they need to alter the initial contract. This is the least desirable of all options and can therefore make working conditions and social relations difficult, even “hostile” at the plant. Several of the men I interviewed partly blamed this for a high turnover rate among young engineers.

      Finally, some product designs inevitably become obsolete, even before they are supplied to the military, simply because of the nature of contemporary war-readiness. This cannot be explained by decisions or difficulties on the part of either client or manufacturer. It represents, rather, the inescapability of entropic loss as a general principle in the material world. This in theory presents problems to any creator of any product, but is amplified in the context of a permanent war economy that demands continual improvements and updates. Simon first explained this to me:

      Another aspect. . .is that this helicopter is flying with six million lines of code or so, because each box is a computer, the radar is a computer, the torpedo is a computer, the bombs are computers, the sonal buoys are computers, and they all have to work together. And a lot of that equipment is obsolete. When the aircraft first gets accepted by the Navy, the computers on board are usually ten years obsolete.

      According to Simon, it is code that goes obsolete the quickest. This would appear to be akin to unplanned obsolescence, assuming producers did not intend for this to happen and that changes in computing are at least somewhat unpredictable. Ironically, creating a product that is already useless waste can occur precisely by attempting to avoid this possibility in pursuit of quality:

      That is because of all this testing, and manufacture. It starts obsolete. When you plan for the aircraft, ship or whatever, you plan for it starting obsolete, and that’s why they have a phase one, a phase two, a phase three of upgrading it. And that’s where you make the money, is in the upgrades. There are classified war games, computer simulations, that you go through. And you know the computer systems of your opponents.

      Simon depicted military equipment that was obsolete as soon as it was sold, a perfect illustration of the dynamics of endless innovation that Baran and Sweezy warned of more than half a century ago. But firms were aware of this: it meant constantly tending to products after they were sold, endlessly producing them in a creative process that never ends until they are decommissioned, destroyed, or both. For this reason, good management, for Eddy (an engineer retired eleven years), meant recognizing that military production is “managing change,” constantly adjusting as products evolve, and as costs and schedules change along with them. Whether the demand to change emerges through interactions with people, process, or product, managing it means trying to avoid waste in its various guises and to preserve value, relationships, and community more broadly.

      Faced with change and uncertainty in their work process, the engineers and accountants I spoke with took pride in their own effort and expertise, first and foremost. That a project might fail to materialize, might be obsolete upon release, or might cost more than initially projected were out of their control by comparison.

      ETHICAL DIMENSIONS: RISK AND BLAME

      Experiences


Скачать книгу