Why "Good Enough" Is One of the Hardest Engineering Decisions

Most engineers are taught how to improve things. Make the circuit quieter. Reduce the error margin. Refactor the unpleasant module. Add another test case. Tighten the tolerance. Shave a few milliseconds from the response time.

We are much less often taught when to put the tools down.

That matters because engineering is full of systems that can be improved indefinitely. Given enough time, money and caffeine, almost anything can be made more elegant, robust or feature-rich. The trouble is that none of those resources is infinite, and caffeine has its own diminishing returns after about the point where your spreadsheet begins to look personally insulting.

“Good enough” is not laziness. Properly understood, it is a disciplined decision that the next improvement is no longer worth what it costs.

Better is not always more valuable

The central question is not whether an improvement is possible. It nearly always is. The question is what changes if you make it.

Suppose a temperature-monitoring device measures within a tolerance that meets the application’s needs, has stable calibration, logs reliably and alerts quickly enough for the process being monitored. Improving its measurement resolution may be technically satisfying. But if the sensor noise, installation method and thermal lag mean the process cannot use that extra resolution, you may simply be producing more digits rather than more truth.

That distinction is important. A system can report 23.147°C with great confidence while the physical arrangement only supports a meaningful answer of roughly 23°C. The decimal places have not made the system cleverer. They have merely dressed uncertainty in a nicer shirt.

The same applies in software. A service that responds in 180 milliseconds rather than 220 milliseconds might be a worthwhile gain, or it might be invisible to users while consuming a fortnight of engineering time. If the actual problem is an occasional five-second timeout caused by database connection exhaustion, polishing the average response time is a very expensive way of avoiding the difficult bit.

Define the boundary before you get attached to the work

Stopping is easier when “done” was defined early.

That does not mean every project needs a grand document full of optimistic boxes and a delivery date that quietly terrifies everyone involved. It means agreeing on practical acceptance criteria: what the system must do, what failures it must tolerate, what evidence demonstrates it works, and what constraints cannot be ignored.

For a connected device, that might include:

• The measurement accuracy required for the decision being made.
• Expected operating temperature, power and connectivity conditions.
• How data is buffered during network loss and what happens when storage fills.
• Alarm delivery time and whether an alert is still useful after a delayed transmission.
• The maintenance burden of calibration, firmware updates and replacing failed hardware.

Those criteria turn vague aspiration into a decision framework. Once they are met, any extra work needs its own justification.

This is especially helpful because engineers can become emotionally attached to elegant solutions. I say “can” in the same way that cats “can” sit in cardboard boxes. Give us a spare afternoon and an untidy implementation, and somebody will be tempted to redesign the whole thing around a more tasteful abstraction.

Sometimes that is exactly right. Often, it is a warning that the task has stopped being driven by user need and started being driven by our own discomfort.

Risk is the proper test

A useful way to assess a proposed improvement is to ask four questions.

First, what failure does this change prevent? Be specific. “It makes the system more robust” is not enough. Does it prevent corrupt records after a power cut? Does it stop a false alarm? Does it reduce the chance of an inaccessible interface blocking a user from completing a task?

Second, how likely is that failure? A severe failure with a credible route to occurring deserves attention. A theoretical failure requiring three broken dependencies, a lunar eclipse and an intern to edit a production configuration may need documenting rather than a six-month redesign.

Third, who carries the consequence? This is where “good enough” becomes an ethical judgment as well as a commercial one. A minor visual glitch in an internal dashboard is different from a missed alarm in a safety-critical setting. A clumsy workflow may be an irritation for some users and a complete barrier for a disabled person relying on keyboard navigation, screen reading or predictable interaction.

Finally, what does the improvement cost? Include more than development time. Complexity creates new failure modes. Extra sensors need calibration. Additional redundancy needs testing. A second cloud dependency may improve availability on a slide deck while creating a marvellous new place for incidents to breed.

The best choice is often not the most sophisticated design. It is the design whose remaining risks are understood, proportionate and managed.

The discomfort of stopping

Many of us find stopping hard because unfinished possibility feels like unfinished work. We can see the rough edge, the missing safeguard, the version-two feature hovering just beyond the horizon. Calling a project complete can feel oddly like leaving the house knowing there is one mug in the sink.

But a product or system that reaches people, does its job and can be supported is usually more valuable than a theoretically superior one trapped in permanent refinement.

This does not mean accepting poor workmanship. It means separating craftsmanship from perfectionism. Craftsmanship asks whether the thing is safe, maintainable, understandable and fit for purpose. Perfectionism keeps sanding a surface long after the furniture has become dust.

There is a quiet kindness in making that distinction, too. It protects teams from burnout and customers from waiting indefinitely for marginal gains they neither need nor notice. It also makes room to address the problems that genuinely matter.

Good engineering is not the art of making everything perfect. It is the harder, more human art of deciding what deserves another week of effort, what deserves monitoring, and what is ready to be trusted in the world.