It's OK if your code is just good enough

Original Article ↗ Hacker News Discussion ↗

Balancing “good enough” code with long‑term quality is a recurring tension in software engineering. Commenters weigh the value of quickly shipping messy but functional code—especially in startups or prototypes—against the maintenance costs, bugs, and slowed feature development that accrue when readability, tests, and clear design are neglected. Many argue that acceptable quality is highly context‑dependent (from life‑critical systems to CRUD apps), but that teams should explicitly agree on quality standards and avoid both perfectionism and cargo‑cult practices that add complexity without real benefit.

Code lifespan and legacy realities

  • Experiences vary widely: some code dies within a couple years, some from the 1990s still runs unchanged.
  • Several note a paradox: “quick hacks” often live longest, while carefully crafted “masterpieces” get replaced.
  • Some argue code not touched is “dead”; others say untouched, working code is success, not failure.

What “good enough” means is context-dependent

  • Many agree: outside safety‑critical systems, “good enough” that ships and solves user problems is usually right.
  • Others push back: “good enough” can be misused to justify spaghetti, bugs, and poor engineering.
  • Contexts differ:
    • Startup with no users: speed and learning trump structure, tests, and abstractions.
    • Mission‑critical systems: reliability and QA dominate, even at huge productivity cost.
    • Typical business apps: aim for a balance, ideally decided explicitly by the team.

Code quality vs product quality

  • Users don’t see code style, but they do see bugs, slowness, and missing features.
  • One camp: bad internals inevitably slow feature work and increase bugs, so quality is an economic necessity.
  • Another camp: over‑engineering, abstraction-heavy “clean” code, and dogmatic rules (DRY, patterns) can hurt usability and delivery more than they help.

Maintainability, collaborators, and process

  • Multiple reports of messy codebases causing slow feature work, firefighting, and frustration for future maintainers.
  • Lightweight practices—tests, clear structure, simple designs—are seen as often not more expensive than sloppy work, once you’re skilled.
  • PR norms and CI are highlighted: code that doesn’t even run is widely viewed as unacceptable for review.

Abstraction, DRY vs WET, and readability

  • Over‑abstraction and extreme DRY are common complaints; they hide behavior, increase cognitive load, and make debugging harder.
  • Others are “terrified of WET code” because duplicated business logic is easy to update inconsistently.
  • Emerging compromise: abstract only when things truly must change together; prioritize locality of behavior and ease of tracing from client code.

Perfectionism, learning, and professionalism

  • Some enjoy striving for near‑perfection as craft or competitive advantage.
  • Others warn that “just good enough” as a mindset stalls skill growth and lowers industry standards.
  • Broad agreement: be pragmatic, discuss quality targets up front, and align effort with risk, domain, and lifespan.