… even moderation.
One of the hardest lessons I ever had to learn in my life – one I still struggle with daily, is that of realizing that usually, “Good enough” is just that. Good Enough.
The problem of course lies in part that – at least in simple programs and math problems – there is no fuzzy “it works.” Things are either correct, or not. As a child playing with the family printer, sending the correct sequence of bytes to a dot-matrix printer resulted in a pretty graphic. Sending another sequence resulted in a jumbled mess. It’s really easy for an incipient geek or computer programmer to fall for the illusion that everything is that black and white, or that at least in the realms of programming or engineering, everything should be perfect.
Of course, it cannot be. For one, people and natural systems are chaotic. Secondly, even engineering is not that straightforward. I learned this lesson the hard way in the Navy, and the teacher was ironically what would appear to be the most unforgiving tutor: maintenance on power plant and propulsion systems aboard a nuclear submarine.
At first glance, that seems ludicrous. The loss of the Thresher almost single-handedly kicked off the birth of rigorous Quality Assurance paperwork and documentation for every critical safety system on submarines. Later, the Iwo Jima had a steam plant leak that killed ten people due to the use of the wrong bolts in reassembling a high pressure steam valve, which subsequently failed. This resulted in a similar program being instituted for surface ships. Obviously there are times where a lack of attention to detail, doing things a little less “perfect” can have deadly results.
The thing is, “perfect” here depends on the standard you wish to achieve. A NASCAR stock racer will blow the doors off a minivan or Humvee, but would fare poorly on anything but the smoothest pavement, and both would be hopelessly mired in conditions that a Humvee would blow through with ease.
Even when you have a primary purpose, there are conflicting standards. On a minivan, the desire for cargo space and the ability to haul said cargo directly conflicts with a desire for fuel efficiency and handling.
The art of engineering, and it is an art, is an art of putting together design choices such that, when all is said and done, the strengths reinforce each other, as many weaknesses as possible cancel out, and the final result is “good enough” at all of its respective jobs.
You have to get used to it.
With submarine maintenance we lived in two worlds. On the one hand, we thoroughly documented the proper installation of the proper material and size O-ring or gasket, with the proper torque applied to the bolts for seawater and steam valves. We obsessively checked off verifying the status of ballast tank valves before a dive. Mistakes got people killed. We spent hours practicing startup and shutdown procedures, done by the book. We drilled over and over again on casualty procedures to hone our response to any problem… and this is where the break with “perfection” began.
There is an “ideal” way to shut down any piece of equipment on a submarine that is listed in the technical reference. There is also a standard startup and shutdown procedure employed as part of the overall ships procedures. In many cases there are even alternate “emergency” procedures, and these are all found in volumes of engineering manuals and procedural guides. Yet there are often discrepancies between what the maintenance and technical reference state for starting up or shutting down a system, and the ships procedures. These differences exist because a motor, a diesel engine, an oil pump, a condenser does not exist in isolation, but as part of an integrated and interconnected whole.
These “standard” procedures are often modified. Revisions are supplied by the Navy as a whole based on maintenance and other accumulated data. The engineer and CO have wide latitude to promulgate changes (“Standing Orders”) as long as said changes don’t break things. They even have latitude to break things and order people into situations that will kill them in order to get the job done.
Lastly, casualty training has a brainstorming component where many what-if’s are asked, because it’s widely understood that when things fail, they’re not likely to fail strictly in isolation (unless it’s relatively minor), but in ways not strictly covered by the manuals.
In short, when things actually break, we don’t throw out the manual, but instead use it to – hopefully – make wise choices in what we’re actually going to do. And often enough we ended up improvising repairs to keep things running when the “proper” parts and tools were unavailable. Maintenance procedures would be pieced together as needed from multiple references, choosing the appropriate steps and discarding those that did not apply.
What I learned, in short, was that instead of striving to meet an arbitrary, unchanging standard of perfect, I should strive to meet the requirements of my priorities, because the real world keeps changing the “specification” you have to meet. Push comes to shove, accomplishing the mission, followed by keeping the ship running and keeping the crew alive trumped nearly every other procedure written down.
And since you didn’t have the time or resources to do everything as perfectly as possible all the time, you had to choose which things must be done “right” – accomplished no matter what – which things should be done well (“good enough”), and which things not to bother doing in the time available, and to be happy with the result of your decisions.
Of course, it never hurts to strive to be a little bit better at whatever it is that you happen to be doing, each time you do it – that is the path to mastery.
