---
name: Design Flaws
slug: design-flaws
type: systemic feature (misclassified as bug)
status: running
version: ∞.0.0
released: "before records began"
maintainer: whoever shipped it last
dependencies:
  - assumptions
  - deadlines
  - overconfidence
  - the person who left the company
license: Irrevocable. Perpetual. Royalty-free to everyone who inherits them.
tags:
  - engineering
  - architecture
  - blame
  - legacy
  - entropy
---

Design Flaws

What it actually is

A decision that made complete sense at the time, preserved in amber, load-bearing.

How it works

A design flaw begins as a reasonable assumption. The assumption gets encoded into a system, a building, a policy, a relationship. The context that made the assumption reasonable then evaporates. What remains is the assumption, now structural, now expensive to remove, now someone else's problem.

The flaw does not announce itself. It waits. It waits for scale, for edge cases, for the one user who does the thing nobody thought anyone would do. Then it becomes a postmortem.

"We always meant to fix that." — every team, about everything

Features

Backward compatibility: design flaws are almost always preserved for backward compatibility. The flaw is the interface now.
Distributed ownership: technically everyone's responsibility. Functionally, nobody's.
Self-documenting: they document, in negative space, every constraint that existed when the original decision was made.
Emergent invisibility: after enough time, they stop looking like flaws. They look like tradition.

Known bugs

ID	Description	Status
DF-001	Flaw identified but cannot be fixed without breaking everything else	Wontfix
DF-002	Flaw fixed in v2, but v2 never shipped	Stale
DF-003	Flaw is actually in the requirements, not the design	Reassigned (to client)
DF-004	"Flaw" is actually optimal given original constraints; constraints are now embarrassing	Closed, disputed
DF-005	Nobody can remember why this works the way it does but removing it caused an outage	Permanent

Edge cases

The flaw is sometimes the only reason the system works at all. Removal triggers cascading failure.
In urban planning, design flaws at sufficient scale become neighborhoods, then become heritage sites.
In human personality, design flaws and character traits are stored in the same data type. Retrieval is ambiguous.
Occasionally, a design flaw in one context is a design feature in the context nobody planned for. This is called serendipity and credited to vision.

Configuration

# /etc/design-flaw/flaw.conf

visibility: low          # increases over time, cannot be set manually
urgency: deferred        # until it isn't
owner: null              # see: bystander effect
fix_priority: backlog    # position in backlog: last
workaround: yes          # there is always a workaround
workaround_documented: no

FAQ

Is this a flaw or a limitation? A limitation is a flaw with better PR.

Can design flaws be prevented? No. They can only be delayed, then inherited by someone with less context and more blame.

Who is responsible? The correct answer and the useful answer are different answers. Pick one based on what you are trying to accomplish.

Should we rewrite from scratch? You are describing a procedure for generating new design flaws on a faster timeline. Yes, many teams choose this.

Changelog

Every version: new flaws introduced. Some old flaws resolved. Net flaw count: increasing.
v1.0.0: initial design. Seemed fine.

drafting spec…