The Hardest Part of Software Engineering Is Knowing When to Stop

The Problem Has Two Directions

When engineers talk about stopping at the right time, they usually frame it as a problem of perfectionism — the engineer who keeps refining instead of shipping. That failure mode is real. But the opposite is equally common and less discussed: the engineer who stops too early, shipping code that doesn't adequately handle failure modes, doesn't have observable behavior, or doesn't meet the actual requirements — and calls it "good enough."

Both are stopping problems. The skill is not learning to stop earlier or later. It is developing the judgment to recognize when the specific requirements of the situation have been met — and to hold that line against both perfectionist impulse and deadline pressure.

The Perfectionism Failure Mode

Perfectionism in engineering is the application of unlimited attention to bounded returns. The difference between an 80% solution and a 95% solution is often a week of work. The difference between a 95% solution and a 99% solution is often another two weeks. These are not always bad investments — it depends on the criticality of what's being built. They are consistently bad investments when the marginal improvement doesn't affect actual user outcomes.

The signs that perfectionism is driving work rather than genuine requirements:

• Refactoring code that works, for reasons of aesthetic preference rather than maintainability or performance
• Adding error handling for failure modes that are theoretically possible but have no realistic probability
• Optimizing for performance requirements that haven't been established
• Designing for scale that is multiple orders of magnitude beyond current need, without a concrete timeline for reaching it

These are not inherently wrong activities. They become a problem when the time they consume delays work that has higher marginal value.

The Under-Engineering Failure Mode

The opposite: shipping work that doesn't meet the implicit requirements of production software. This often happens under deadline pressure when "good enough" is interpreted as "technically fulfills the feature description."

Production software has a set of requirements that are rarely in the ticket but are always real:

• It needs to be observable (logs that tell you what happened, metrics that tell you it's running correctly)
• It needs to fail gracefully (not propagating failures into unrelated parts of the system)
• It needs to be operable (someone who didn't build it can debug and manage it)
• It needs to handle the edge cases that will actually occur in production, not just the happy path

Stopping before these properties are satisfied is not pragmatism. It is creating deferred work that will be paid for in operational pain and emergency fixes.

The Judgment Between Them

The judgment between these two failure modes requires clarity on what "done" means for the specific work, which requires understanding the context:

What is the criticality? Code on the critical path of payment processing has different "done" criteria than a feature on an admin dashboard used by five people. The former warrants additional investment in correctness and observability. The latter can ship with a tighter scope.

What is the expected change frequency? Code that will be modified frequently needs more investment in readability and maintainability. Code that will be stable for years can accept more technical debt.

What are the actual failure modes under production conditions? Not theoretical failure modes, but the specific things that happen in your system. If your third-party email provider has 99.95% uptime, designing for its complete unavailability may not be worth the complexity. If your payment provider has a 0.1% timeout rate, designing for payment timeouts is absolutely required.

The Specific Tools

Checklists can help make "done" criteria explicit. Before marking any significant piece of work complete:

• Is the happy path correct and tested?
• Is the most likely failure mode handled gracefully?
• Can you tell from logs and metrics when this is running correctly and when it isn't?
• Would someone who didn't build this be able to debug an incident with it?
• Have you stopped adding things that aren't in the above list?

The last item is the stopping criterion. When all the requirements are met and the only remaining work is improvement beyond the requirements, stop.

The Practical Takeaway

For your next piece of work, write the done criteria before you start: the specific requirements — functional and operational — that this work must meet. When all criteria are satisfied, ship. If you find yourself continuing to work after the list is complete, name what you're doing and ask whether it's worth the time. Often it isn't. Sometimes it is. Make the choice explicitly rather than drifting.