|
|
posted: January 30, 2024
tl;dr: There’s a downside to doing more than is necessary...
I have to be careful not to over-engineer this blog post.
Many projects and designs fail because sufficient resources and time are not put into them. The end result has a deficiency, and is not able to function over the full range of operating conditions. Ultimately it fails, sometimes in a spectacular manner (see the original Tacoma Narrows Bridge).
There is, however, another type of failure, which is less obvious. In this failure, the end result actually performs flawlessly for its entire expected lifetime. But too many resources and time were put into its creation; a lesser design would have been sufficient for the task at hand. Those resources and time could have been used elsewhere on another project, to solve another problem. This is the failure of overkill, or over-engineering. It’s the opposite of the original Tacoma Narrows Bridge problem: it is the “Bridge to Nowhere” problem. Once completed, a Bridge to Nowhere sees far less traffic than expected. It either has too many lanes or never should have been constructed in the first place. An inexpensive ferry might have sufficed, and the money better spent elsewhere.
Why take a four-wheeled vehicle when a two-wheeler suffices?
Examples of overkill abound, although it often takes some skepticism to see them. The U.S.A.’s roads and highways are replete with them. As someone who prefers two-wheeled vehicles (bicycles and motorcycles) to four-wheeled ones, I often will select one of my two-wheelers for a trip; most of my fellow citizens choose a four-wheeler by default. Each of my two-wheelers (two are motorized, two run on pedal power) has different characteristics, so that I can select the minimal one needed for a particular trip. Side note: the minimal one is also usually the most fun one. There’s a guy in my neighborhood who lives by himself and has not one but two nearly identical full-size General Motors SUVs, the kind that can seat nine. I try not to leap to final conclusions without fully understanding someone else’s situation, but I wonder what his thought process is. He really doesn’t have a choice when it comes time to take a trip, even though he has two vehicles.
The popularity of SUVs and pickup trucks over cars is a major example of overkill. I realize that there are regulatory incentives in place that bias U.S. vehicle manufacturers and consumers towards SUVs and pickup trucks. But often people justify their purchase of large vehicles by claiming that, occasionally, they will need the seating and/or hauling capacity. That may be true, but if that only happens a few times a year, why not buy a smaller vehicle and rent a large vehicle when it is needed? When I was working in Boston during my college years, I didn’t have a car at all. I would just rent a car if I wanted to take a weekend trip to the countryside. Many people forget about the option of renting.
In the software realm, where I work, the overkill or over-engineering is widespread but hard for users to see. Users might notice it as sluggishness of an application or website, or huge memory requirements. As a software engineer who gets to peer under the hood to see how the software is architected, designed, and constructed, the overkill is obvious. Often there are additional layers of abstraction that are not absolutely needed. Code can almost always be streamlined to run faster and more efficiently. The best design practice is to code for simplicity from the beginning.
Simple, elegant solutions are best. They free up time and resources that can be spent on solving other problems. There are plenty of problems to be solved in each of our lives and the world as a whole. By avoiding overkill we can solve more of them.