The Great Enterprise Hoarding Disorder

I'm just going to say it: if you are still fiercely defending "reusable infrastructure" and the sacred temple of DRY in the year 2026, you are suffering from a clinical hoarding disorder, and your codebase is a stinking, ceiling-high stack of 1998 newspapers. Writing "reusable Enterprise code" today is exactly like having a psychotic roommate who refuses to throw away a half-eaten pepperoni Hot Pocket, and instead decides to construct a custom, cryptographically secure, climate-controlled mini-fridge in the hallway—wiring it up to the main breaker panel, writing a custom device driver in Rust just to monitor the ambient humidity, and running a dedicated coolant line through the drywall—just in case the apartment needs that crust to scale later. The crust is completely unnecessary. It is moldy. We have a replicator that can materialize infinite fresh Hot Pockets for half a cent, yet you are still hoarding stale bread in your little custom appliance because someone in a 1999 Java seminar told you it was "accretive."

This pathology was on full, screaming display recently when the internet collectively lost its mind over Andrej Karpathy's admission that he just "vibe codes" now. Reading that thread was like walking into a hoarder's intervention where the victim is clutching a rusted soup can and sobbing about the structural integrity of the tin. The commenters were absolutely terrified of subtle bugs in the boilerplate, frothing at the mouth over the loss of deep, deterministic control over the abstract syntax trees, and weeping about the lack of rigorous test coverage on scripts that are essentially meant to be thrown away after ten seconds of execution. This reaction is fundamentally irrational—it is the visceral, animal panic of a religious zealot who spent ten years learning to knit a reusable, multi-threaded microfiber cloth out of their own chest hair, only to watch someone else casually wipe up a spill with a disposable Bounty paper towel and toss it in the garbage.

Ouch.

Somehow, over the last two decades, the pragmatic advice of Don't Repeat Yourself (DRY) mutated from a reasonable safeguard against copy-paste errors into a deranged cult chanting meant to justify endless, masturbatory hoarding. We were brainwashed by early 90s object-oriented dogma into treating every single line of code as a sacred artifact, wildly expensive to produce, and desperately in need of generalization, abstraction, and preservation in amber. You know the repos I am talking about. You have stared into the abyss of a repository where a simple lexical scoping problem requires a deeply nested, multi-layered inheritance hierarchy of AbstractFactoryProviders that smell exactly like old cat pee and rotting fast food wrappers. The repos where a simple postorder traversal of a DOM tree requires you to instantiate seven different singleton manager classes just to print a string to the console.

Yup.

Look, I get why this happened. I really do. I watched this hoarding disease spread through the trenches, observing the carnage across half a dozen death-march projects where developers were pushed to the absolute brink. Back in the late 90s and early 2000s, writing code was physically painful. We were typing out C++ on spinning-rust hard drives, and if you wanted to change a single method signature in a base class, you were looking at a forty-five-minute compilation cycle. You'd hit compile, go get a coffee, play a game of foosball, have a minor existential crisis in the breakroom, and come back just in time to watch the linker violently shit the bed because you forgot a semicolon in a header file.

The absurdly high friction of creation triggered a deep-seated industry trauma response. Engineers decided that code was precious. Like, literally precious. I remember looking into one giant monolithic C++ codebase around 2003 where everyone was terrified to duplicate a simple string manipulation function. Some doomed engineer had spent three weeks—three entire weeks of their fleeting mortal life—building a generalized, polymorphic, template-metaprogramming-based string tokenizer. It was a monstrosity. It had iterator traits, custom allocators, and a lexical analyzer that could theoretically parse ancient Sumerian if you fed it the right config file. Why? Because the tech lead had decreed that writing a simple while loop to advance a char pointer was "not accretive." The team desperately needed a Platform Component.

Fast forward to the Java 1.5 era, and the disease metastasized. Now we had Generics! We had annotations! We had an entire generation of developers who suddenly realized they could write code that writes code that eventually does nothing. Solving business problems took a backseat to writing "frameworks." The industry built massive, baroque hierarchies of AbstractSingletonProxyFactoryBeans, all dedicated to the holy mission of ensuring that nobody ever had to type select * from users more than once. The prevailing wisdom dictated that reaching the theoretical maximum of DRY—abstracting away every single noun and verb into a reusable FactoryProvider—would trigger a state of nirvana where software just wrote itself. That self-writing software utopia never materialized. The actual result was a digital landfill of tightly coupled, hyper-fragile dependency graphs where updating a logging library in one microservice would somehow break the billing system in a completely unrelated department.

Every time a novel business requirement pops up, the immediate reflex is to pry open the biometric lock on the hallway mini-fridge, shove the new requirement next to the 2014-era XML payloads, and bolt on another layer of parameterization, convinced that this pile of crap-ass garbage is actually a "platform."

The brilliant Kellan Elliott-McCrea recently articulated exactly why this hoarding instinct is mathematically dead by drawing a massive, terrifying distinction between merely writing code and the blood-pact of canonization. Cory Doctorow echoed the exact same existential threat over on Pluralistic, detailing how this canonization process—turning cheap, transient scripts into eternal, heavily fortified library functions—acts as an active sabotage of your own agility. Naturally, the hoarder-monks are aggressively fighting back, shrieking their lungs out in the Hacker News discussion thread for the Doctorow piece because they are terrified of losing their status as the high priests of the mini-fridge. Canonized code is eternal. It demands human sacrifices in the form of infinite maintenance, backward compatibility constraints, and labyrinthine regression testing. It forces you to maintain strict type safety, appease the Hindley-Milner type system, and carefully tune the polymorphic inline caching optimization on a piece of logic that literally just formats a date string for a temporary marketing dashboard that a product manager is going to abandon next Tuesday anyway. AI token-burning makes code generation so insanely cheap that the whole concept of accretive library-building is a complete mathematical scam. We can just ask the machine to emit the raw, un-abstracted logic, run the script once to fix the database migration, and yeet it into the sun.

End of story.

But try telling that to the neighborhood homeowners association. If you want to understand why this disease is so deeply entrenched, you have to look at the twisted Big Tech performance review culture that actively incentivizes and rewards maximum hoarding. I was talking to an engineer I know recently about a promo committee that functions exactly like a deranged suburban HOA, throwing a literal parade for a guy who spent eight solid months building a chonkulous, generalized, fully polymorphic XML parser framework. This engineer built a cathedral of garbage. He stuffed six entire mini-fridges full of meticulously documented, fully abstracted parsing rules—complete with custom dependency injection containers and massive interface contracts—just in case the enterprise ever needed to parse XML on a smart toaster, and the promo committee slapped a Staff Engineer badge on his chest for his "cross-functional architectural vision." Meanwhile, any actual, working hacker could have solved the exact same business requirement by writing a four-line Perl script, running it as a cron job, and going home early to play video games. A four-line Perl script doesn't get you a promotion, because a Perl script is disposable. The promo packet is just a hoarding catalog. It is a glossy, heavy-stock magazine showcasing exactly how much rotting pizza you managed to cram into the codebase under the guise of "leverage" and "reusability."

Let's be incredibly clear about what happens when you treat code as a permanent, accretive asset in an era where AI models can synthesize entire functional domains in seconds. You end up building elaborate, bespoke packaging for dog poop. I was reading a whitepaper the other day about how engineering teams are still spending twenty percent of their sprint capacity strictly maintaining internal helper libraries—libraries that do nothing but wrap HTTP calls or manage basic state transitions using heavily abstracted directed acyclic graphs (DAGs). These developers are treating their custom DAG implementations like family heirlooms. They polish the nodes, they carefully optimize the edge traversal, and they write thousand-word commit messages defending their architectural purity. Meanwhile, an LLM can spit out the exact HTTP request you need, tailored perfectly to the specific edge-case of the microservice you are touching right now, without dragging in forty megabytes of generalized dependency wank. The hoarder looks at the LLM output and cries about how it violates DRY because it repeats a pattern. Yes. Because it is a paper towel. Nobody washes a paper towel. Nobody refactors a paper towel. The entire point is to wipe up the spill and immediately hurl the soggy mess into the garbage where it belongs.

"But Gus!" I can hear you screaming through the screen, slamming your mechanical keyboard in rage. "What about Tech Debt?! What about when we need to pivot the core business logic and we have fifty disposable, duplicated scripts floating around instead of one central, generalized, beautiful library?!"

I hear you. You are having a panic attack about the structural integrity of your trash pile. You think that if you don't neatly organize the rotting crusts, the health inspector is going to shut you down. The brutal truth is that your business logic is crap-ass anyway, and when it inevitably needs to pivot, carefully refactoring that highly coupled, DRY-compliant monument to 2018 is completely off the table. Instead, expect to spend six weeks trying to untangle a catastrophic cyclic dependency graph before weeping openly at your desk and threatening to quit. Vibe coding and AI token-burning render refactoring completely obsolete. The mathematically correct move now is to throw the moldy crust in the trash, wipe up the spill with a fresh paper towel, and generate a completely new, context-aware script from scratch.

Go figure.

Anyway, my blood pressure is spiking and my dog needs a walk. The garbage truck is coming tomorrow morning to clear out the bins, and I suggest you go figure out what to throw away before they do it for you. I'm going to bed.