The world of software development is full of declarative documents happy to tell you the RIGHT WAY TO DO THINGS. From the Agile Manifesto to the Twelve Factor App, there is no shortage of opinionated, sometimes overwrought, statements of purpose that a new or forming development team can adopt in order to quickly align themselves on any number of methodology and process decisions.
The time may eventually come when a team may also benefit from using the same approach to write their own manifesto, documenting their internal standards and practices. This can be especially useful for a large project that will involve many architectural decisions or bring together team members not accustomed to working together towards a common goal.
While time consuming, the process of formulating a manifesto for a project can force a healthy debate about important questions, while keeping things light and not bogging the team down in mind-numbing design documentation -- a particular advantage for teams employing an Agile methodology.
In this session, we will first examine a number of well-known and popular development manifestos, including ones with particular resonance or applicability for the Drupal community. Next, we will look at a real-world case study of a development team that used the manifesto approach to reduce uncertainty at the beginning of design and development on a major initiative to do a ground-up redesign of their custom distribution in Drupal 8. How did this process work? What benefits or challenges has it produced for the team and their stakeholders? How does the result compare to traditional design documentation?
Paul is a Senior IT Manager at the University of Texas at Austin, where he leads a team of Drupalists in building and maintaining websites and custom distributions for the campus community. He has been involved in Drupal since 2009, and has co-organized multiple Drupal community events for higher-education.