Principles behind the Slow Manifesto
We follow these principles:
Our highest priority is to satisfy the customer through the delivery of bug-free software, even if it takes longer. Haste is the enemy of trust — a system that doesn’t break is worth more than ten releases full of patches. If the deadline tightens, delete the deadline, not the quality.
Changes in requirements must be carefully evaluated, even when they arise late. Slow processes prefer stability over reactivity, aiming for predictability for both the customer and the team. And if the change is really merely “change the button color”, let the customer pick it in the system.
Deliver working software in long, well-planned cycles, from a few months to a year, with preference for the time scale that allows quality. Those who deliver too fast usually deliver too wrong.
Business people and developers must work asynchronously and documented, avoiding constant meetings that dissipate focus and extend deadlines. If it can be resolved by email, don’t schedule a meeting. If it can be resolved by document, don’t send email. If it can be resolved by coffee, send coffee.
Build projects around stable teams and well-defined processes. Give them the environment they need and trust the planning — not improvisation. A rotating team is like a team where nobody knows where the code is, and everyone blames the previous person.
The most efficient and effective method of conveying information to and within a development team is through clear and lasting documentation, not conversations that evaporate. Documentation exists. Slack doesn’t.
Bug-free software is the primary measure of progress. Working is not enough — it has to work right. If the user has to click three times where one would suffice, something went wrong.
Slow processes promote sustainable development. Sponsors, developers, and users should be able to maintain a constant pace indefinitely — no exhausting sprints, no burnout. If someone needs energy drinks to code, the process is wrong.
Continuous attention to long-term architecture and design increases stability. Preventive refactoring is better than reactive correction. Legacy code is not legacy — it’s the foundation nobody wants to reform.
Simplicity — the art of maximizing predictability and minimizing rework — is essential. Less novelty, more maturity. If the framework has more features than you use, maybe you don’t need it.
The best architectures, requirements, and designs emerge from experienced and well-integrated teams, not from rotating groups that dissolve at the end of each sprint. Accumulated knowledge is worth more than scattered documentation.
At regular and spaced intervals, the team reflects on how to become more effective — and then refines and adjusts its behavior slowly and with criteria. Process change also deserves stability. If it works, don’t touch it. If it doesn’t work, wait a bit before touching it.