The Pathology Driven Development Manifesto
A satirical manifesto of seven delivery anti-patterns — formalism over common sense, testing in production, people as replaceable parts. Written from real projects. If one sounds familiar, you have a problem.
Some years ago, after a particularly instructive project, I wrote down a methodology.
I called it Pathology Driven Development. It has seven principles. I did not invent any of them — I watched every one being practised, by competent people, with straight faces.
Here it is, unedited. Then we will go through what each one costs.
The PDD ManifestoFormalism over common sense.Tools and processes over working code.People are fully replaceable.When something is not yes, then quick is better than well done.You don't have to test — but when you do, it must be at least the production environment, or higher.Introduction of a new feature breaks existing code. This is the critical key to implementing successful PDD.If you strictly follow the steps above, you no longer have to worry about documentation, test coverage, or anything else basically.
If any of these made you laugh in a slightly tired way, you have worked somewhere I have worked.
1. Formalism over common sense
The template gets filled in. Every field. The document goes to review, comes back with formatting comments, and is approved.
Nobody asks whether the thing being described makes sense. The ritual of the artefact replaces the purpose of the artefact, and the meeting ends on time, which is what everyone will remember about it.
You spot this when the review comments are all about how something is written and never about whether it is true.
2. Tools and processes over working code
A new tool arrives to solve a problem that was never diagnosed. Configuring it takes a quarter. Adoption is mandated. Three sprints later, half the team maintains a parallel spreadsheet because the tool does not fit how the work actually happens.
The tell is simple: nobody wrote down which capabilities were missing before the tool was bought. Do that first and the honest answer is usually that most of what you need is reachable through configuration of something you already own.
3. People are fully replaceable
Two testers with identical job titles are treated as interchangeable units of capacity. Reassign the story, reassign the person, the throughput number stays the same on the plan.
What actually moves with the person is context — the analysis they sat through, the reason a field matters, the memory of what broke last time. None of it is in the ticket.
This one has a defence, and it is worth the effort: write every test case for a stranger. Explicit login, explicit navigation, explicit data state, no implicit knowledge. Standardisation feels like bureaucracy right up until the moment your work is handed to someone who was not there, and then it is the only thing that matters.
4. When something is not yes, then quick is better than well done
An estimate is challenged. Not with new information — just challenged, in a meeting, by someone senior. The number goes down. Nothing about the work changed.
The interesting cost is not the missed deadline. It is that the next estimate will be pre-deflated by the person giving it, because they have learned what happens to honest numbers.
5. You don't have to test — but if you do, at least in production
My favourite, because it is the only one people say out loud.
It arrives disguised as pragmatism: the lower environment is not representative, the data is stale, we will validate properly after go-live. Sometimes the environment genuinely is unusable — and that is a real finding worth escalating, not a reason to move the test to a place where failures reach customers.
The version I find harder to argue with is quieter: a fix verified in an environment where the original defect could not even be reproduced. Green tick on the path that was never sick.
6. New features break existing code — that is the key
Read literally it is satire. Read as a description of an organisation with no regression suite, it is a policy.
If nothing guards what already worked, then every release is a fresh experiment, and the only detection mechanism is a customer. Teams in this state usually do have a regression suite. It is simply never updated, and everyone has quietly agreed it is useless — which is worse than not having one, because the empty ritual still consumes a day per release.
7. Follow all of the above and you can stop worrying about anything
This is the real point of the manifesto.
None of the six principles above is fatal on its own. Together they compose. Formalism produces documents nobody trusts; distrust of documents makes testing feel pointless; pointless testing makes regression pointless; broken regression makes every release a gamble; and the gamble is absorbed by whoever is on support that week.
At that stage, nobody is worried about documentation or coverage, exactly as promised — not because the problems were solved, but because the standard has moved to whatever gets through today.
Why I Still Keep This List
Not to be cynical about it. Every one of these anti-patterns was adopted by intelligent people under real pressure, and each one was locally rational on the day it started.
I keep it as a diagnostic. When I join a programme, I read the seven points and count how many are present. Zero is a fantasy. One or two is normal. Four means the quality problem is not in the code, and no amount of test cases will fix it.
How many of the seven are running on your programme right now?