Scrolls
3 min read
On this page

Good Enough vs Perfect

Every task has a point where additional effort stops producing meaningful results. Knowing when to stop optimizing is one of the most valuable skills you can develop, whether you are cleaning your house, writing an email, or building software.

The instinct to make something perfect feels responsible. But perfection has a cost — and that cost is often invisible until you have already spent too much.

The Everyday Version

Cleaning the House

Imagine guests are coming over in two hours. You have two approaches:

Approach A: Deep Clean Everything
- Scrub every baseboard
- Organize every drawer
- Polish every surface
- Time required: 6 hours
- Result: Immaculate, but guests arrive to find you still cleaning

Approach B: Make It Presentable
- Clear visible clutter
- Clean the kitchen and bathroom
- Vacuum the main rooms
- Time required: 90 minutes
- Result: Comfortable, welcoming space with time to spare

Approach B is "good enough." Your guests will not open your drawers. They will not inspect your baseboards. The effort to go from presentable to immaculate is enormous, but the difference your guests actually notice is tiny.

Writing an Email

You need to ask your neighbor if they can water your plants next week.

Draft 1 (2 minutes):
"Hi! Could you water my plants next week while I'm away?
I'll leave the key under the mat. Thanks!"

Draft 7 (45 minutes):
"Dear [Neighbor], I hope this message finds you well.
I am writing to inquire whether you might be available
to assist with the care of my indoor botanical collection
during my upcoming absence from..."

Draft 1 communicates everything needed. Drafts 2 through 7 added nothing useful — they just consumed 43 extra minutes. The message was good enough on the first pass.

Cooking Dinner

A recipe says to dice onions into perfect 5mm cubes. You can spend ten minutes achieving uniform cuts, or two minutes doing a rough chop. The soup tastes the same either way. The difference between "roughly chopped" and "perfectly diced" matters to a restaurant presentation — but not to a Tuesday night dinner.

Why We Over-Optimize

Several psychological traps push us toward perfection:

Trap 1: Loss Aversion
- "What if someone notices the imperfection?"
- Reality: They almost never do

Trap 2: Sunk Cost
- "I've already spent 3 hours on this, might as well finish"
- Reality: Those 3 hours are gone regardless

Trap 3: Identity
- "I'm the kind of person who does things right"
- Reality: Doing things right includes knowing when to stop

Trap 4: Fear of Judgment
- "People will think I'm lazy"
- Reality: People value results delivered on time

Connecting to Technology

Premature Optimization

One of the most quoted rules in software comes from Donald Knuth:

"Premature optimization is the root of all evil."

This means: do not spend time making code faster before you know it is too slow. Many developers spend hours optimizing a function that runs once at startup, while ignoring a loop that runs thousands of times per second.

Example: Building a photo-sharing app

Premature optimization:
- Spend 3 weeks building a custom image compression algorithm
- App has 12 users
- Nobody notices the image quality difference

Good enough first:
- Use standard JPEG compression
- Launch the app
- If 100,000 users complain about load times, THEN optimize images

The 80/20 Rule (Pareto Principle)

In many systems, 80% of the results come from 20% of the effort.

Website Performance:
- 20% of the fixes (compress images, enable caching)
  solve 80% of the slowness
- The remaining 80% of fixes (custom CDN, code splitting,
  lazy loading every component) solve the last 20%

Bug Fixing:
- 20% of the bugs cause 80% of user complaints
- Fix those first, not the obscure edge case that
  happens once a year

Minimum Viable Product (MVP) Thinking

An MVP is the smallest version of a product that delivers value. It is the "presentable house" of the tech world.

MVP approach to a ride-sharing app:

Version 1 (MVP):
- Riders request a ride
- Drivers accept the ride
- Basic payment works
- That's it. Ship it.

NOT the MVP:
- Ride scheduling for next week
- Split fare with friends
- Driver rating system with badges
- In-app music selection
- Estimated carbon footprint per trip

All those features might matter later. None of them matter
if nobody wants the basic product.

Diminishing Returns

Every system has a curve where improvement gets harder and more expensive.

Test Coverage Example:
- 0% to 60% coverage: Easy, fast, catches most bugs
- 60% to 85% coverage: More effort, still valuable
- 85% to 95% coverage: Significant effort, moderate value
- 95% to 100% coverage: Enormous effort, minimal extra safety

Time spent vs bugs caught:
  |         _______________
  |        /
  |       /
  |      /
  |     /
  |    /
  |___/
  +------------------------
  0%    50%    85%   100%
        Test Coverage

The curve flattens. Each additional percentage point
costs more and delivers less.

How to Decide When to Stop

Ask yourself these questions:

1. Who is the audience?
   - Yourself? Lower the bar.
   - A paying customer? Find their actual standard.
   - A regulatory body? Meet the exact requirement.

2. What is the cost of imperfection?
   - Nobody notices → stop now
   - Minor inconvenience → probably stop
   - Safety risk → keep going
   - Legal liability → keep going

3. What else could I do with this time?
   - If the answer is "something more valuable," stop optimizing here

4. Am I past the knee of the curve?
   - Early improvements are big and cheap
   - Late improvements are small and expensive
   - Once you feel the effort climbing, reassess

Knowing When Perfect Actually Matters

Good enough is not always the right answer. Some situations demand precision:

When "good enough" is fine:
- Internal documentation
- Prototype code
- First draft of anything
- Choosing a restaurant for lunch

When perfection matters:
- Medical device software
- Financial calculations
- Security authentication
- Bridge engineering
- Legal contracts

The skill is not "always be sloppy" or "always be perfect." The skill is recognizing which situation you are in.

Common Pitfalls

  • Treating everything as high-stakes. Most decisions are reversible. Save your perfectionism for the irreversible ones.
  • Optimizing the wrong thing. Spending hours formatting a report nobody reads while the actual deliverable is late.
  • Confusing effort with value. Working hard on something does not automatically make it more valuable.
  • Skipping the "good enough" check. Before refining further, ask: "Would anyone notice or care about this improvement?"
  • Gold-plating after the deadline. Delivering a perfect result late is worse than delivering a good result on time.
  • Applying MVP thinking to safety-critical systems. "Move fast and break things" does not apply to brake systems or medical records.

Key Takeaways

  • "Good enough" is not laziness — it is a deliberate decision about where to spend your effort.
  • The 80/20 rule applies almost everywhere: most of the value comes from a fraction of the work.
  • Premature optimization wastes time solving problems that may never exist.
  • Diminishing returns are real. The last 10% of improvement often costs more than the first 90%.
  • Always ask: "What is the cost of stopping here?" If the answer is "not much," stop.
  • Save your perfectionism for situations where the cost of imperfection is genuinely high.