The Saboteur's Guide to Software Projects

One of the funniest reads for large orgs is the declassified "Simple Sabotage Field Manual" (1944): the CIA (then OSS) guidelines for the Resistance on underhandedly destroying productivity.

A few years back, I took a sharpie and highlighted for a friendly client which destructive ideas (especially in chapter 11) are deeply ingrained in their corporate policies and culture. 😅

Based on that, let me introduce the "Saboteur's Guide to Software Projects": a tongue-in-cheek playbook for 100% guaranteed project failure.

The list is open to contributions — feel free to share your evil suggestions below!

Prepare your sharpie now:

Failure-Seeding Planning #

The planning phase sets the foundational traps that will detonate later.

1. Always insist on making software projects as large as possible. Nothing is out of scope.
2. Point out that some agile projects also fail, and so insist on doing waterfall. Blame outside factors (procurement, budgeting, etc).
3. Insist that the software can be only launched to users when every last part is ready.
4. If someone insists on at least phases/milestones, make sure that no actual software gets released: make the milestones about "deliverables" which are documents.

Requirement-Minefield Specs #

Since you do Waterfall, you need up-front Specifications: insist on detailed requirements, in writing, before any code is written.

1. You must have detailed Specifications. But who does it? There are two ways to do this, just never mix them:
   • A) Find people who believe they know what the end user needs (project managers, bosses, etc): let them specify, so half the actual requirements don't get discovered.
   • B) If the real end users specify, also good: They will detail only the business functionality, and completely forget about the parts they don't see: infrastructure, user administration, monitoring, backups, etc.
2. Over-specify some things that are actually incredibly expensive to implement, like 100% uptime. (Surely the difference between 99.9% and 100% uptime requirement must be only 0.1% of the project cost? It's just logical.)
3. Use a lot of vague expressions like "user-friendly", "immediately", the system "must ensure" but never say how, etc.

Division-Sowing Organization #

Project organization is your foundation for inflicting delays — primarily by increasing handovers: create as many independent-but-not-autonomous teams as possible, so none can achieve anything without coordinating with others.

1. First, bring in consultants to organize the project. Don't start anything before their recommendations are fully implemented.
2. Establish at least two management forums with different agendas where the project will be discussed regularly. There should be as little personnel overlap between the forums as possible.
3. For interfacting systems, demand weekly status meetings, with as many participants as possible, for the whole duration of the project.
4. Make sure that only managers attend these status meetings, to avoid accidentally creating a forum where technical people can discuss technical details.
5. Do not disseminate important information in channels but rather only in messages or verbally, and only to half the people whom it might concern.

Morale-Crushing Development #

Development is hard to sabotage with a good team — so crush morale instead.

1. Insist that developers come to the office all the time, and make sure the office have as many distractions as possible, preventing deep work.
2. Don't do automated tests, insist that they slow down development and make refactoring harder. (Nevermind that you don't actually allow time for refactoring.)
3. Make sure code review focuses only on nitty-gritty details instead of keeping the architecture intact and simple. Make it a long wait time too!
4. Insist on written documentation as early as possible, preferably in advance. Discredit other, less expensive methods of information transfer as "not serious".
5. Tie your developers to deadlines. Make sure these deadlines do not take into account refactoring, other work, etc.
   • Bonus points: you can even have them estimate: developers always estimate the "happy path" time, so to make deadlines surely slip, all you have to do is just to not add any contingency. It's their fault now, and you're also destoying quality as they rush to keep deadlines!

Endless-Testing Nightmare #

At this point the software is "feature complete", and stakeholders assume that it's nearly ready for go-live after a quick testing round. Oh, how wrong they are. Since the software has never actually met the reality of the end users yet, it will be full of wrong assumptions, missing critical details, and big parts will end up never to be used.

1. Try to still delay putting the software into the hands of the end users. Other people (managers, testers, etc) who believe they know what the end user needs should do acceptance testing.
2. This phase allows for a lengthy multi-rounds manual testing and fixing death loop that can go on for months, if not years.
3. This should be the first time the software meets the infrastructure, never before! Have strict firewall rules, and require detailed documentation and approval for each port opening request. (Bonus points: firewall changes only on Wednesdays. True story.)
4. This is the phase when the inadequateness of the initial specifications will come to light. Nevertheless, label every change request as "bug", thus destroying the team's morale further.
5. Do not pay suppliers until your endless stream of "bugs" (actually change requests) are 100% completed. Their owners will run after their money and make their teams implement your changes in cheaper and cheaper ways, thus letting you drive software quality to rock bottom.

Knowledge-Destroying Ops #

In this phase, your focus should be on destroying know-how and cementing the project into an unchangeable state.

1. Make sure that the software is operated by people who were not involved earlier. If you have a dedicated OPS team who doesn't DEV, that's perfect.
2. Immediately let go of any suppliers, and put every internal developer onto remote projects.
3. Double move: Fire some key people now (thus destroying knowledge) who you can later scapegoat for the inevitable failure (thus securing your own position).
4. Leave behind immense amount of useless and misleading documentation. Your earlier efforts will help a lot here: it's guaranteed that all of them are out of date.
5. Final tomb: demand that any change from now on requires a costly and long repeat of the security audit.