As a life-long Midwesterner, I haven’t spent a lot of time on the beach. However, I managed to build enough sandcastles during my youth to know that hours of effort can quickly disappear underneath the waves of a rising tide. No matter how beautiful the structure, how perfect its lines and curves, it stands no chance against a powerful sea that seeks to level everything it can touch. If the sandcastle is to be admired for more than a few hours, it has to be rebuilt. Time and time again, one must construct the sculpture, fully aware that it will erode as high tide sweeps in. Of course, the joy of construction disappears after a few days. But the destructive nature of the tides is unrelenting, so one must build the sandcastle once more.
Although I’ve long since forgotten where I picked up this sandcastle metaphor, I often use it when thinking about the life cycle of engineering projects. It is deceptively easy to believe that the job is finished once a device, or system, or methodology has been designed. However, as soon as that design is released into the real world, it will begin to erode. Surfaces idealized as perfectly smooth by the designer acquire minute ripples during the machining process. Electronic signals pick up noise, hydraulic pumps leak, bearings seize, and chemical solutions degrade. As a result, maintenance is a large portion of the engineering workload. Many engineers spend their careers doing nothing but keeping industrial processes operating smoothly. And anyone responsible for maintaining a house built more than twenty-five years ago knows that there is a significant cost, both in time and currency, associated with keeping a once-pristine structure in proper working order.
Although nature can do significant damage to an engineered system, the most severe problems are often people-related. Managers forget the caveats placed on equipment specifications, and begin demanding unrealistic production rates. Operators forget rules about proper usage, and begin to utilize machinery in applications for which it was not intended. Engineers fail to ask enough questions when integrating equipment into larger systems. And so the erosion accelerates. Devices, systems, and methodologies, once so lovingly designed to serve a particular purpose, begin to break down as they are misused, misapplied, or misappropriated.
System failure is not always a bad thing, as it may lead to knowledge of how the scheme might be improved. But it is usually a unwanted outcome, and keeping a system running smoothly requires diligent observation. A supervision style known as Management By Wandering Around involves checking in with employees, in a casual and unstructured manner, and asking questions about how things are going—so as to discover how processes and procedures might be improved. This methodology emphasizes identification of unexpected complications, as it focuses on newly-arisen issues, and is not intended as a replacement for standard performance reports. In a similar manner, frequent inspections are required to keep engineered systems operating on a reliable basis.
Although failures can be reduced via analysis during the conceptual and design phases, the most difficult problems are usually unanticipated. Thus, one can never assume that a system is “done.” I regard as cruel any engineer who tosses a design “over the wall” and walks away without regard for others who must subsequently maintain system functionality. All physical processes have to be observed, analyzed, maintained, and tweaked to offset the unrelenting tendency of nature to maximize randomness. Steel will rust, capacitors will short circuit, and out-of-spec materials will find their way into the process.
Likewise, interpersonal understandings may have to be reconstructed on a regular basis. Managers may need to be reminded as to their original agreements about specified performance. (Keeping a contemporaneous notebook is quite useful in this regard.) Operators may require a bit of nudging to return to proper operating procedures—although this should be done with an open mind, as they may be ready and able to show why the procedures should be revised. Colleagues may benefit from a better understanding of how a prior-generation system was intended to operate. But none of this can happen if an engineer holes up in a cubicle, and refuses to interact with others. There has to be a willingness to walk the beach, just to see how the sandcastle is fairing.
When engineering students are asked to carry out design projects in a period of a few weeks, just getting their design to function properly is a sufficient challenge. However, during semester-long activities, such as a senior design project, young engineers need to be made aware of the multitude of forces that may cause their designs to decay. Where possible, designs should account for the eventualities of repair, maintenance, and disposal. These issues are certainly of less immediate importance when one is thrashing about, trying to get a new design to simply work. However, as a design is refined and improved, the life cycle of the system deserves serious consideration.
Engineering graduates should also understand that, during the course of their careers, they will likely run into financially-focused managers who will tell them to put off maintenance, or goal-driven managers who may ask them to run systems outside of specification. There are sometimes quite legitimate reasons for doing such things, and the political clout to countermand such decisions is frequently beyond the engineer’s reach. But they should attempt, to the best of their abilities, to reconstruct the agreements and understandings that constrained the original design work. In a perfect world, this should not have to be done. But it usually falls to an engineer to deal with the physical consequences that result from such managerial decisions. So engineers should learn early on that, sooner or later, someone will have to go out and rebuild the sandcastle.