Over the years I have developed a passion for seeing software projects fail. I love the feeling of breakdown and despair they cause to everyone involved in them. Failed projects break teams, make companies loose money, disappoint clients and burn out the people engaged in them. They have a beautiful destructive potential.

If you love to to sabotage projects but don’t know how, don’t worry, I’m here to help. I’m going to walk you trough some of the techniques and methods I’ve developed over the years to sabotage my own projects. Think about this a a guide, crafted specially for you who are pursuing the joy of failure in your software project.

There is really beautiful stuff in here. I’ve actually given cool names to every technique.

Without further ado, here we go!

The Vaporware Sales Pitch

You know, developers are expensive. You most likely won’t be building something from the ground up and then sell it. No no. You want to make sure that, before you or your company invest money in building something to sell, you actually have buyers for it.

This seems reasonable, but don’t be deceived. It has a beautiful potential to bring confusion and pain to your project. You see, the only thing that can convince someone to buy something they have not seen is the power of promises. And promises, my dear friend, are our best ally in the quest for a successful project failure: they are hardly remembered past the sales pitch, they are often unrealistic and extremely hard to keep. “Does/will the system do this?” asks the innocent buyer, “Sure it does! It can do that and more!” replies the salesman. “Can you do it in three months?", “No problem at all!".

So, promise as much as you can of your imaginary something you don’t have. That is an essential first step. At the end of the day, you don’t have to keep the promise, you just have to make sure others keep them for you. Work smarter, not harder!

The Pointless Estimation

Once I asked a builder how long it will take him to build me a house with four bedrooms, 2 toilets, kitchen, living room and a nice garage; oh, and how much it will cost me. He asked me for some plans, and I told him I had none. Then he asked me a bunch of questions about sizes, materials, lands, styles, water pipes, etc. Man! I just wanted to know if how long and how much it will take him before planning anything. What a boring guy!

Developers are not that way, they are nicer. If you push them enough they will give you an estimation. That is because they don’t have that “professional” sort of attitude in them. Maybe is because some of them didn’t even go to uni anyways.

It does not matter if you have a clear scope of what is needed or not, they will give you their gut feeling eventually. If they resist, emphasize that you are demanding something really simple. “Look, I don’t want you to build it, I just want to know roughly how long. Is that too hard?". Then, once you have your estimation, you can hold them accountable to it. It was their word, so they have to keep it.

This creates the perfect atmosphere for your project to fail. As the deadline approaches and progress is not made at the expected pace, they will get scared. You should know that fear is the number one cause of failed projects: it causes everyone involved in the project to make rushed, uninformed decisions and to give up quality for compliance. Cultivate that feeling and you are guaranteed things will be done wrong, and pressure will ramp up to very high levels.

Design is for Designers

Some developers insist in doing what they call “system design” work. Under no circumstances allow them to do that. It’s true, amateur project saboteurs will allow them doing this because it moves the project slower, and a project with an unmet deadline is a total failure, right? Well, you know, in my experience that has not been always the best move. You see, a software with good design, that works well, it can really please a client. It can please them so much that they might be willing to accept delay in some other items. It is always a bold move to bet on the unmet deadline as a project failure.

The best alternative here is that they just focus on writing code, and not thinking about the system. Actually, a poorly designed system, even though is faster to achieve, will slow them down eventually as the unforeseen things come to happen. It is crucial that they don’t discover the unforeseen by asking questions, researching or trying to anticipate. Keep the meetings short and you will be able to cut those conversations to a minimum. If they get really annoying, you can always play the KISS card. Most developers don’t know the difference between simplicity and convenience anyway.

Convince them that design is for designers, and that they are just developers.

Chinese Whispers

If fear is the number one cause of failed projects, then poor communication is the number zero! If there is anything you would take from this little article, take this: don’t let people communicate! You’ll have a guaranteed failure!

Of course, what I mean here is not “no communication at all”. You would be easily caught in your efforts to make the project fail if that were the case. No no, what you need here is to provide an illusion of communication, like when playing chinese whispers. Set one or two meetings a week, but just between the development team. Then arrange for someone else to be the communication funnel between the developers and the stakeholders. It’s impossible that that person will be able to keep up with the flow of information coming from each side. Something will be missed, or misrepresented, or misinterpreted. That’s what we want!

Here is the trick really. Under no circumstances developers and stakeholders should be ever in the same meeting or in close communication. It is too dangerous, because understanding between the two groups could develop and that could make the project a success.

This is by far one of the most powerful strategies to make your project fail. Developers can have their meetings about their technical stuff, which in turn will distract them of the heart of business problem to solve. This reinforces the fact in their heads that their job is purely technical problem solving. Under no circumstances they must believe that their job is of an empathic nature: understanding the users and their needs. No no, that will lead them to do their job well.

You shouldn’t have issues doing this, as most developers are socially awkward: they don’t really like people nor interacting with clients. Use those developers to reinforce to the more “social” ones the idea that that is not their job to do that.

The Counterfeit Agile

This is very related to the previous tactic, but deserves a topic of it’s own. You must make sure developers are doing Agile and not being agile. There is a difference. You see, agile is an adjective, not a noun.

As long as they think that agile means using Jira, estimate using story points and divide work in sprints of some duration, you’ll be fine. They will think their job as developers is reduced to just closing tickets and they will never go beyond that.

You want them to eat and breathe the commercial Agile, that thing some companies branded and sold as a methodology for project management. They must never know that agile is a set of values and principles. They must believe is methodology. If they discover the real meaning of it, they will want to apply it, and that could be the success of your project. Don’t let that happen!

Actually, one effective thing you can do is talk to your ISP and tell them to block this website from the company internet. Again, they must not read the principles, because they are in direct contradiction with all the advice that I’ve been giving you here.

Actually, you might want to block this video too. Just in case.

And if someone ever want to discuss whether we are doing real agile or not, shut down the conversation immediately by saying “We do sprints, we estimate in story points and we use Jira. Of course we are doing Agile!” Don’t let them reply and mock them for asking such a silly thing. No one will dare to ask the question ever again.

The Vague Jira Card

So, since we are doing counterfeit agile, requirements have to come from somewhere, right? Well, we put those in Jira, of course. But you don’t want to put requirements in Jira in a good way. Jira might be tricky software, but it can certainly organize a team if used correctly. Here’s a pro tip: use Jira as a mere placeholder of statements, or even better, link it with confluence and spill over the two of them some vague information. Double effect: now apart from understanding vague stuff, they need to figure out where it is!

When specifying the work to be done, never explain the why or how. No no, that gives the developer a margin to think. Just say what needs to be done and in the most vague way possible. “The client wants this” followed by screenshots of other systems is a great way to waste precious development time for guessing what it needs to be done.

I’ve mentioned before that developers should not think. Let me rephrase that: they should not think about the bigger picture of the problem they are trying to solve, or about system design, or about the users and their pains. That’s out of the question. But the longer you can keep them puzzled on the question of what is it that the client really wants with a certain requirement or feature, that’s a win right there.

They will loose time trying to guess, and when they give up they will go to our fiend the funnel, and they surely will miss some precious info on the back and forth, which will guarantee things are done wrong or simply not done at all. Have you started to see how every technique plays so well with each other?

The Official Technical Stack

Some projects are really complex in nature, so they might need proper tooling in order to effectively achieve the desired results. Developers really like to come up from time to time with new and better tools to add to the stack. It is crucial to project failure that they do not use the right tool for the job.

Instead of a proper queue system like SQS, Rabbit or Kafka, have them implement a queue in Postgres. Instead of a search engine like Redis Search or Elastic, have them index things on a SQL table. Instead of a graph database like Neo4j, have them implement a materialized path or a nested set. Event Sourcing database? Use MySQL with triggers!

Even better, if they use a framework chances are some no-brainer packages for all these things are already available. Have them use them. They will prove inflexible at some point, specially if they are poorly developed, and then is when things get sweet for trouble.

Here, most developers will be your allies. They are strange creatures indeed! They are thought almost every day that there are no silver bullets, but they would willingly use the same tool for different things just for the sake of convenience. They will disguise this convenience as simplicity: use this in your favor.

There will be some who will try to push for these tools. Don’t let them. Explain that the company has a technical stack that is already defined.

When the time comes to scale, a poorly chosen tool can really make things difficult on a project. This does not always happen, but is a good card to keep in your arsenal.

There are so many other things I can think of for making a project fail, but I’m short on time. Maybe I will compile them into another article some other time. For know, this should give you enough material to wreak havoc.

Happy project failing!