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.
A single component absorbs responsibilities until it becomes the system itself
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.
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.
GOTO spaghetti (1960s) evolved into God Objects (1980s). The mechanism changed from unstructured control flow to unstructured responsibility, but the result is the same: systems too complex to comprehend
Both result from failing to distinguish what is needed from what is available — one at load time, one at design time
God objects accumulate dead branches — as responsibility grows, code paths become unreachable but undeletable
Year
1985–present
Context
Object-oriented programming arrived with a promise: model the world in objects, and the code will organize itself. Early OOP practitioners — C++ in the late 1980s, Delphi and VB in the 1990s — started with a single class. They added methods. Then more methods. Then state. Then more state. The class grew because it was easier to extend than to redesign. By the time anyone noticed, the class was 8,000 lines long and touched every table in the database.
Who Built This
Everyone. Solo developers building line-of-business apps. Enterprise teams under deadline pressure. Open source maintainers who merged every pull request. The God Object isn't a mistake — it's the natural consequence of incremental development without architectural review.
Threat Model at Time
"It compiles and the client is happy" was the acceptance criteria. Nobody measured coupling, cohesion, or cyclomatic complexity. Most teams didn't have code review. The class worked. It just couldn't be changed.
Why It Made Sense
A single class with all the logic is easy to find. You never wonder "where does this live?" — it lives in the God Object. Autocomplete shows every method. Debugging is linear. For a solo developer shipping an application, this is rational.
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.