Garbage Perpetuation Development (GPD) — You can’t believe how bad the existing code base is, but you’re afraid to open a can of worms, so everything you add to it is written in the same style. For the rest of your life, you can say, “It was like that when I got here.”

Eighteen years later and this is somehow more relevant, not less. what nobody saw coming is that now we have LLMs-based coding assistants trained on the entire internet, which means they’ve ingested billions of lines of GPD-produced code and will cheerfully suggest the same patterns right back at you. I remember reading a darkly funny thread on this from Simon Willison, or someone on Twitter, where they note that Copilot and friends are essentially the world’s most confident GPD practitioner, i.e. they’ll mirror whatever style surrounds them without judgment.

Mansion in the Quicksand Development (MQD) — The opposite of Garbage Perpetuation Development, you are so shocked by the poor quality of the existing code that you vow that you’d rather swallow razor blades that code the same way. So you write a tight beautiful refactored masterpiece that will crash as soon as the underlying database loses its integrity (later tonight).

Joel Spolsky’s 2000 post “Things You Should Never Do, Part I” was already making this point about Netscape’s catastrophic rewrite, and yet we keep doing it. I believe the reason this pattern persists is that the beautiful new code feels like progress (I personally still like how the git blame shows my name next to clean principled work) and the rotten foundation is invisible until it isn’t. The 2022-era wave of “we’re migrating from our monolith to microservices” produced a fresh epidemic of this, stunning new service boundaries built on top of a PostgreSQL schema that hadn’t been touched since 2009 and was quietly on fire.

Defer to the Framework Development (DFD) — You’re not sure how to tackle quite a few critical design/architecture issues, so you convince your boss to adopt the framework du jour and decide to “let it handle it”. As soon as someone needs something that the framework doesn’t handle, you blame management for making such a myopic technology decision and say that it can’t be done. You keep your job and get a new boss every two years.

This post was written in 2009, which means the Rails hype cycle was at absolute peak. Looking back, the framework-du-jour carousel has spun so many times since then; Backbone → Angular → Ember → React → Vue → Svelte → htmx, that “DFD” is now practically a job title. The irony is that React, which became the dominant “let it handle it” choice for the better part of a decade, is now itself the thing people are fleeing. Addy Osmani has written about the cost of JS framework churn and how each migration has tended to cost far more than the original adoption.

Not Invented Here Development (NIHD) — The opposite of Defer to the Framework Development, as soon as you discover something the current framework can’t handle, you abandon it and write all your own routines. Everything now works exactly as you want it, but with all the additional code to maintain, your backlog has just grown from 6 months to 2 years.

Some of the most NIH-afflicted organizations (early Amazon, early Google) turned their internal reinventions into products (AWS, Bigtable/BigQuery) and ended up winning. The rest just quietly accrued two-year backlogs as described. The honest version of NIHD’s calculus is that owning your stack gives you deep understanding but the cost compounds ruthlessly over time (Kellan Elliott-McCrea wrote about this during his time at Etsy).

Whoever Screams Loudest Development (WSLD) — Just as the name implies, you work for the customer who screams the loudest. If anyone screams louder, you drop everything and work on their project.

F-Bomb Development (FBD) — Whenever everyone is screaming so loud you can’t hear anything, you work on the project of the customer who drops the most F-bombs.

This one is timeless.

Start Over Development (SOD) — A critical requirement cannot be supported by the current architecture, so you decide to rewrite it. You spend 3 months designing the new architecture and then 6 months writing the new code. You never finish because you’re out of business. Now you know what “critical” means.

The autopsy for this pattern remains Spolsky’s Netscape post, but the case study that really drove it home for a generation of developers was the Friendster-to-Facebook transition and, more painfully, the Digg v4 rewrite in 2010, which effectively killed the company. The 3-month architecture phase feels like real progress and generates real excitement, and again, it’s the most enjoyable part of software development for a lot of people.

Workaround Development (WAD) — The opposite of Start Over Development, you can make the current system do anything. You are so clever with your extra algorithms, functions, and databases. Even with all your great variable naming and comments, six months later, you have no idea how anything works.

Foote and Yoder named this the “Big Ball of Mud” in their 1999 paper of the same name, and their observation that it’s actually the dominant architecture in production systems worldwide remains one of the most quietly devastating things ever written about software. It often produces genuinely working software for longer than any of the cleaner approaches (arguably) the system is alive, users are happy (arguably), and it’s only the next developer (or future you) who pays the price. Ward Cunningham’s original framing of “technical debt” was meant to describe exactly this tradeoff: borrowing against future understanding to ship today.

Code Generation Development (CGD) — You’re so tired of writing the same code over and over, that you write a code generator to do it for you. What used to take a week only takes a few hours with the new tool. But you’re no further ahead because 80% of your time is needed to enhance and maintain the code generator.

This one did not age the way the author expected. The code generation problem got absorbed by an industry: first by scaffolding tools, then by platform engineering teams, and eventually by LLMs. The new version of this is that you spend 80% of your time writing and maintaining prompts instead of a generator, which is arguably the same trap with a different texture.

Infinite Prototyping Development (IPD) — Your customers and users are unable to describe or document their requirements. So you spend lots of time with them understanding their business and when you’re ready, you throw together a prototype. They love it, but it needs just a few changes. You keep making changes, but it always needs more. It stays a prototype forever. When the app crashes because of security or scaling issues, you’re off the hook because, “It’s only a prototype.”

The Lean Startup movement (Ries, 2011) tried to rehabilitate the prototype by renaming it the MVP and giving it a lifecycle, so the “forever prototype” is a failure of process, not of the artifact itself. It helped somewhat. What it didn’t fix is the social contract problem at IPD’s core because once stakeholders have seen something running, they shift from “requirements document” to “change request,” and you can never get them back. Many people do not know this but React was originally an internal Facebook prototype that just… never stopped (React is still referenced ironically in the 0ver satire).

Infinite Analysis Development (IAD) — You never have to do anything because you never have specs. Woo hoo!

The Agile Manifesto was signed in 2001, eight years before this post, specifically because this had become the dominant mode of enterprise software development through the 1990s. And yet here we are in 2009 still writing about it, and here it is in 2026 still happening in every organization large enough to have a dedicated “architecture review board.” If the thing you’d build is going to be wrong, not building it yet has real value. The problem is that the people practicing it rarely know which situation they’re in.