Manifesto for Fluid Software Development

We are excited to bring a radical new way of software development to the industry.
We fluid evangelists are determined to perfect the art of building software by spreading the word of fluid software development.

Frozen-Core Values

Constant change instead of plans and agreements
Moving forward instead of learning lessons
Embracing the waterfall of ideas instead of searching through a scrum of thoughts
Impose principles on others instead of listening to reason

Even though we acknowledge the existence of the items on the right, we value only the items on the left

Authors

Mike Rotch	Anita Bath	Seymour Butz
Oliver Klozoff	Ima Wiener	Bea O'Problem
Ranil Wijeyratne	Jacques Strap	Al Coholic
Amanda Hugginkiss	Hugh Jass	Waylon Smithers
Ura Snotball	Ollie Tabooger	Moe Ron
Maya Normusbutt	Yuri Nator	Ahmed Adoudi

The 20 Fluid Principles

Our highest priority is to satisfy the customer through waves of valuable software.
Welcome changing requirements, even late in development. In fact build your software so that varying requirements are the feature.
Define freezing and thawing periods between and after release waves.
Software built in a fluid manner is always bug free, but some parts may smell fishy.
Only a continuous incorporation of every new framework & library can guarantee a consistent development flow.
Instead of major and minor releases we speak of low and high tide release waves.
Business people and developers must work in pools throughout the project.
The best architectures, requirements, and designs emerge out of the blue, where blue is its German figuratively meaning.
Still being able to process liquids is the primary measure of progress.
The most efficient and effective method of conveying information to and within a development team is by talking with a mouth full of water. In hot environments ice cubes are also accepted.
Simplicity--the art of minimizing the amount of work--is essential.
Software can only be improved by piping it through every process and tool at hand.
Measure your teams performance by awarding so called viscosity points. It’s up to the team to decide whether a low or high viscosity is considered "being in the flow".
Physics can be applied in fluid processes: where high pressures lead to warm temperatures, which lead to low viscosity points.
Build projects around motivated individuals. Provide them with enough fluids to reach the ballmer peak.
The number of team members must at all times equal the number of third party libraries used within the software.
A new team leader is selected daily by sitting in a circle and spinning a bottle of gin.
Everybody who doesn't notice there aren't actually 20 fluid principles must wear a hat of shame.

© 2018, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.

Site design and photograph by Ranil Wijeyratne and intended to resemble the agile manifesto

Should you find a typo, feel free to keep it.