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.
Initialization loads everything because distinguishing "needed" from "available" requires understanding the system
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.
Both result from failing to distinguish what is needed from what is available — one at load time, one at design time
Both consume resources they should not — health checks under stress, initializers at startup. Same mechanic: observation/preparation becomes consumption
Year
1993–2002
Context
Desktop applications ruled enterprise software. Every CRM, every ERP had a main form that loaded at startup. The pattern was universal: load everything the user might need, then show the form. On a local database with 3,000 records, this took milliseconds. When the business grew to 50,000+ records, it took minutes. Nobody changed the code.
Who Built This
Enterprise developers building line-of-business applications. Often Delphi, VB, or PowerBuilder shops. They built what worked at demo scale and shipped it to production scale.
Threat Model at Time
Performance wasn't a security concern. It was a user experience annoyance. Nobody measured startup time because the database started small.
Why It Made Sense
Loading everything at startup meant the application felt instant after the initial load. Every combo box populated. Every grid filled. The user never waited for a query. The trade-off was rational — pay once at startup, never pay again. Until the data grew.
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.