Tuesday, April 21, 2015

Manifesto for Blame Driven Development

Manifesto for Blame Driven Development

Performance Improvement Plans and Firing People over Resources and Interactions

Bug Triaging over Working Software

Personal Agendas over Customer Collaboration

Endless Debates over Responding to Change

That is, while the items on the right will give us a chance to succeed,
we value covering our ass over a possibility to do something meaningful.


Principles behind the Blame Manifesto

Our highest priority is to deflect blame for all problems
through early and continuous failure of others.

Welcome changing requirements, even late in
development. Blame processes harness change
for opportunity to delay commitments.

Deliver non-working software infrequently, from a
couple of quarters to a couple of years, with a
preference to the longer timescale or not at all.

Business people and developers must make
vague and incomplete requests of each other 
daily throughout the project.

Build projects around depressed resources.
Give them judgement and punishment,
and watch them squirm.

The most efficient and effective method of
conveying information to and within a development
team is domination and intimidation.

A high bug count is the primary measure of progress.

Blame processes promote sustainable employment.
The sponsors, developers and users should be able
to maintain employment for an indefinite period 
regardless of their inability to honor commitments.

Continuous attention to technical incompetence
and poor design enhances blame-ability.

Simplemindedness — the art of maximizing the amount
of useless conversations—is essential.

The best straw men architectures, incomplete requirements and aimless design
emerge from withholding information.

At regular intervals, the team reflects on who
needs fixing, then tunes and adjusts this person’s


Here is a blog post with an example of implementing Blame Driven Development.


  1. Operationalise this for maximum stakeholder enbiggening and execute! Executionate!