Manifesto for Clunky Software Development


We are uncovering „some“ ways of developing software by doing it and helping others do it not like that. Through this work we have come to invalidate:

Digital tools over true interactions and lean processes

Working software over delivering (customer) value

Assumptions over customer collaboration

Directionless floating over strategic thinking

Dogmas over continuous improvement

That is, while we told there lies some value in the items on the right, we are not in the mood to appreciate them right now.

Principles behind the Clunky Manifesto

We follow these principles (although we shouldn’t):

Our highest priority is to finish the sprint story through fulfillment of the requirements hidden in the story.

Changing requirements will delay our development. Clunky processes avoid change, since the customer will not recognize anyway.

Do not deliver working software until you are sure you cannot be held responsible for upcoming bugs.

Business people are business people. They dress differently, talk differently and do not understand us developers anyway.

Build projects around your individuals. Give them the environment which worked for others and relate some well-proven software engineering KPI to their bonus scheme.

The most efficient and effective method of conveying information to and within a development team (in decending order) is E-Mail, Jira, Teams, WhatsApp, Webex, Mural, and Twitter. Oh, and 5G.

Getting things into the „done“ column is the primary measure of progress.

Clunky processes promote clunky software. Thus, the sponsors, developers, and users should be able to maintain their own pace.

Technical excellence and good design need time, and thus are postponed until the new CIO wants us to replace the clunkiness with his/her/its own interpretation of agility.

Clunkyness – the art of maximizing the amount of work done – is essential.

The best architectures, requirements, and designs emerge from the systems architects, known for their expertise in developing ANSI-C libraries.

At regular intervals, the head of change management reflects on how to become more effective, then tunes and adjusts all teams‘ behavior accordingly.