Development Manifesto

Posted by Attila Györffy on .

Development Manifesto

Posted by Attila Györffy on .

A manifesto is a published verbal declaration of the intentions, motives, or views of the issuer, be it an individual, group, political party or government. -- Wikipedia

The other day I just read through the 501 Manifesto again. Perhaps you have seen it also, it is a document that became quite relevant in the last few years... If you haven't seen it yet, go and have a look at it yourself, otherwise continue reading.

Upon reading through the document I started to think:

If the 501 Developer stands up at 5:01pm sharp to leave work, how do they make the most out of their time whilst they are still there?

Time spent right

While I sympathize with most of what is within the document mentioned above, I felt the need to express what the values are that I'd like to keep in mind whilst I'm still spending my time at work.

This is a draft version of the values I personally feel strongly about, I use them mostly as guidelines to create a working environment where I can be productive and have a sense of achievement. This keeps me going, keeps me being excited about what I do for a living.

This document is NOT in any way meant to be a guideline to everyone and perhaps in some cases it might not be relevant to you. However, keeping the following in mind helped me to significantly increase my own and my team's overall productivity and sustainability.

Disclaimer: This is a work in progress document that was heavily inspired by the 501 Developer Manifesto.


  • Accessible communication over one-to-one direct messages
  • Constant improvement over habits (Retrospetives are useful)
  • Trust in the team's decision making ability over micromanagement


  • Timeboxed meetings over long running conversations
  • Clear business requirements over unspecified stories
  • Conversations on pull requests over the inclusion of technical debt
  • Focussed communication over irrelevant details


  • Continuous delivery over huge releases
  • Automated tests over human errors

Team Dynamics

  • Team responsibility over a set of individuals
  • Decentralized team over geographical limitations
  • Transparent knowledge sharing over resource bottlenecks


  • Simple solutions over out-of-scope problems
  • Incremental improvements over huge user stories (use of must, should, nice to have)
  • Broad estimation over precise story points
  • Celebration of achievement over endless development cycles

Personal Development

  • Taking pride in quality over constant utilisation
  • Availability of experimentation over constant utilisation
  • Acquiring new knowledge over using the same tools all over and over again


  • Self-explanatory code over written documentation and context switching
  • Architecture over cutting corners
  • Convention over configuration
  • Community-wide conventions over custom solutions
  • Highlighting of technical debt over surprises in delivery


  • Business use cases over technology driven design

The document above uses the Do What the Fuck You Want to Public License [link]