Keyboard Navigation
W
A
S
D
or arrow keys · M for map · Q to exit
← Back to exhibits
Complexity & PerformanceDesign FlawEXP-022

ENIAC — The First Programmers Debugged with Their Hands

When there was no line between hardware and software

1940s–50s · Physical Wiring · 3 min read
Pattern Classification
Class
Complexity Accretion
Sub-pattern
Responsibility Collapse
Invariant

Systems do not become complex. They accumulate complexity — one reasonable decision at a time — until no single person can hold the whole in their head.

This Instance

A single component absorbs responsibilities until it becomes the system itself

Detection Heuristic

If understanding a single change requires understanding the entire system — if a class handles responsibilities that span multiple domains — if code exists that no one can explain but no one dares remove — complexity has accreted past the point of comprehension.

Same Pattern Class
Why It Persists

Every codebase experiences this. The force driving accretion is time itself — combined with changing requirements, changing teams, and the economics of "just add it here." Refactoring is expensive. Accretion is free. Until it isn't.

This section is being excavated...

Archaeologist's Note

This pattern has been found in applications built by talented developers at respected organizations across every decade of software history. Its presence in a codebase is not a reflection of the developer who wrote it — it is a reflection of what that developer was taught, what tools they had, and the path that was easiest given what they were taught. The goal is not to find fault. The goal is to find the pattern — before it finds you.

Katie's Law: The developers were not wrong. The shortcut was not wrong. The context changed and the shortcut didn't.

The FoundationThe Dawn Room1 / 11
Museum MapNext Exhibit