How to Build Software That's Doomed to Fail, in 6 Easy Steps

A practical guide for anyone who wants their next big software project to end in a cancelled go-live, written from years of watching the method work perfectly.

Building software that fails is surprisingly hard. You need discipline, consistency and, ideally, a large budget. Luckily, over the years I've watched some real professionals do it, and I've taken notes.

Follow these six steps and I can almost guarantee your project will end the traditional way: late, over budget, and with a steering committee meeting where everyone agrees it was the framework's fault.

Step 1: Set the go-live date first

Design is a detail. Requirements are a detail. What matters is the date, and the best dates come from the sales team, a contract, or a board slide, ideally before anyone technical has seen the project.

Once the date exists, protect it. When the engineers explain that the date is impossible, nod, thank them for their "concerns", and remind everyone that the date is in the contract. Physics will adjust.

Bonus points if the date is a Monday after a long weekend, so the whole migration can happen while everyone is "available".

Step 2: Create one team that everyone depends on

Pick one team to build the shared library, the platform, the core, whatever you call it. Then make every other team depend on it.

Five teams waiting for one team is called alignment. It looks great on an architecture diagram: everything points to the middle, like a very organised traffic jam.

The central team will be overloaded within a month, so give them more responsibility. Route every technical decision through them too. If something is waiting on the core team, it's clearly important, and if everything is waiting on the core team, it's clearly very important.

Step 3: Never decide who owns what

Clear responsibilities are a sign of distrust. In a healthy organisation, everyone owns everything.

So when a feature touches two teams, don't decide. Let it sit between them, like a parcel on the doorstep of two neighbours who each think it's for the other. Three sprints later, ask in the steering committee why it isn't done. Both teams will have an excellent answer, and both answers will point at the other team.

Step 4: Let the teams fight over features

Competition breeds excellence. If two teams both want to build the same feature, let them. You'll get two implementations, two data models, two sets of bugs and a very lively integration phase.

Even better, let teams fight over the features nobody wants. Those fights are quieter, and they last longer.

Step 5: Cultivate a hero

Every doomed project needs a hero. One person who knows how everything works, never writes anything down, and saves every release at 2 a.m. with a fix nobody else understands.

Celebrate them. Thank them in every all-hands meeting. Make sure every incident goes straight to them, so nobody else ever learns how the system works.

The hero is irreplaceable, and that's the beauty of it. Right up until the day they hand in their notice, at which point the project discovers it was never a project. It was one person with a very large backlog.

Step 6: When it fails, blame the framework

The project is late, the go-live has moved three times, and the steering committee wants answers. Don't look at steps 1 to 5. Look at the technology.

The framework is outdated, the architecture was wrong, the previous vendor didn't understand the business. The solution is obvious: a complete rewrite, with a new framework, a new vendor and, most importantly, a new go-live date.

Which brings you back to step 1. Congratulations, you've built a cycle. Some companies have been running it for decades, and I'm occasionally hired to help them get out of it.

OK, seriously

Every step above is something I've seen on real projects, and none of them came from bad people. They came from pressure, good intentions and nobody stopping to say "wait".

The boring cures are:

Let the people who build it help set the date, or at least the scope that fits the date.
Keep shared teams small and their scope clear, and let other teams contribute instead of queue.
Write down who owns what, even when it feels bureaucratic. It's cheaper than three sprints of polite finger-pointing.
When two teams want the same feature, decide in a day, not a quarter.
Treat a hero as a risk, not a strategy. Pair them, rotate them, make them write things down, and thank them for that too.
Before blaming the framework, check steps 1 to 5. It's almost never the framework.

None of this is new. That's the funny part: we've known how to avoid most of these for decades, and the method above still has an excellent success rate.