Is "clean code" always worth the time, or is "good enough" sometimes fine?

Question

Accepted Answer

**It depends on the code's lifespan and blast radius.** Clean code pays off handsomely for code that lives and changes; "good enough" is the right call for throwaway, prototype, or rarely-touched code. The skill is matching your investment to the situation — avoiding both sloppiness and gold-plating.

## The principle: match effort to the code's life

Code quality is an **investment**, and like any investment its return depends on time and exposure. The two questions to ask:

- **How long will this code live?** Code read and changed for years deserves clarity; a one-off script does not.
- **What's the blast radius?** A core module touched by many people and depended on by critical paths warrants care; an isolated corner that rarely changes does not.

## When clean code clearly wins

- Code that **changes often** — clarity is paid back every time someone reads or edits it.
- **Shared, central, or long-lived** code — the cost of confusion multiplies across people and time.
- Anything where a **bug is expensive** — payments, auth, data integrity.

## When "good enough" is the right call

- **Throwaway code** — spikes, experiments, one-time migrations, a script you'll delete tomorrow.
- **Prototypes** meant to validate an idea, not to survive.
- **Rarely-touched, low-risk** code where polishing buys little.

## The two failure modes

| Failure | Looks like | Cost |
|---|---|---|
| **Sloppiness** | shipping mess into code that will live | slow future changes, bugs, erosion |
| **Gold-plating** | over-engineering code that won't matter | wasted time, premature abstraction |

Both are real waste. "Good enough" is a *deliberate, contextual* choice — not an excuse for carelessness, and not a license to polish forever.

## Why it matters

This question separates engineers who apply quality **dogmatically** from those who apply it **economically**. Treating clean code as a religion wastes effort on throwaways; treating it as optional rots the systems you depend on. Senior judgment is knowing *which kind of code you're holding* and investing accordingly — and being able to explain that tradeoff is exactly the kind of pragmatic thinking teams want to see.

Failure	Looks like	Cost
Sloppiness	shipping mess into code that will live	slow future changes, bugs, erosion
Gold-plating	over-engineering code that won't matter	wasted time, premature abstraction