Feranor

How to Destroy a Project in 5 Steps

The following guide is provided as a public service. If your goal is to maximize chaos, ensure total loss of accountability, and achieve legendary status among the future developers who will maintain your codebase, this is for you.

For everyone else: consider it a field guide to recognizing what's already happening in your organization.

Step 1 — Skip the contracts. You know what you mean.

Why waste time writing interface contracts when you can just call the other module directly and figure it out as you go? After all, you wrote both modules. You know exactly what they do.

Your colleague who joins in six months will also definitely know. And the colleague after that. The contract will emerge organically from the stack traces.

The cost of a missing contract is paid in full, with interest, at the worst possible moment: usually production.

Step 2 — Everyone owns it. Which means everyone can touch it.

The best way to ensure maximum engagement is to make ownership collective. No single owner means no single point of blame.

It also means no single point of responsibility, no single point of decision, and no single point of anyone actually fixing anything. When the module breaks at 3am, the resulting group discussion will be fascinating.

Shared ownership is a polite term for no ownership.

Step 3 — Just push to main. It's fine.

Branch protection rules are for people who don't trust their team. You trust your team. So you push directly to main. Your colleagues also trust their team, so they push directly to main.

Nobody reviews anything, because everyone is trustworthy. The merge conflicts will build character.

Trust is a cultural value. Branch protection is a structural guarantee. Only one of them works at 3am.

Step 4 — The infrastructure lives in someone's head.

Why write Terraform when you can just click through the cloud portal? It takes twenty minutes and you remember exactly what you did. Mostly.

The staging environment is slightly different from production, but that's probably fine. Nobody has touched the production environment in eight months and everyone is afraid to. This is called stability.

An environment that cannot be reproduced from code cannot be trusted, recovered, or audited.

Step 5 — The monolith was fine, actually.

Microservices are overengineered. Modules are bureaucratic. Contracts are overhead. The monolith was simple, elegant, and everyone understood it.

Until it had 400,000 lines of code, three people who understood any given part of it, a deployment that took four hours and required a prayer, and a bug in the notification service that took down the payment system.

But it was simple.

Simplicity at the start is not the same as simplicity at scale. A monolith is a deferred complexity tax with compound interest.

The punchline nobody laughs at

If you recognized your current project in any of these steps, you're in good company. These five patterns aren't exotic failures. They are the industry default. Present in startups and enterprises, in greenfield projects and decade-old systems, in teams of three and organizations of three hundred.

That's exactly what makes them dangerous. None of them looks like a decision. Each one is just the path of least resistance, taken one harmless shortcut at a time, until the shortcuts intersect with the wrong moment.

The good news: their predictability is precisely what makes them preventable. Every one of these patterns has a structural counter. Like a contract, a named owner, a protected branch, an infrastructure definition, a module boundary. None of them requires heroics. All of them require deciding, in advance, that the path of least resistance is not the path.