The first responsibility of any development team is to Get Shit Done. This simple motto covers a lot of territory.
There are no easy or quick answers to these questions.
Software is a living creature that requires constant love and care. We do not simply write code once and call it done -- it will require maintenance as we add new features, fix bugs, and scale our applications to meet larger workloads. We believe that investing in quality in the present will pay off in increased throughput in the future.
Quality can mean something different to different developers; however, a good rule of thumb is that high quality code can be easily maintained, especially by somebody other than the original author. This means that code should ideally be readable, easy to understand, easy to verify that it follows the spec, and easy to extend when necessary. In practice, this means not only following best practices when designing and writing code but also communicating with the rest of the team to share knowledge about each program.
The difference between a team of developers and a group of developers working independently is communication. Communicating effectively is hard! Each of us needs to evaluate what sorts of information to share, determine how to express that knowledge effectively, and be good at listening to others as they communicate. On top of this, we also need to be able to reconcile when people have different opinions and learn to agree or disagree.
A large part of this document will discuss our best practices around communication; however, our first principle of communication is, "when in doubt, always overcommunicate."
We adopted the principles of Humility, Respect, and Trust from the Team Geek book. This book aligns with a lot of our values, and we highly recommend that each developer read it. If you don't have a copy, ask Donnie to order you one.
Paraphrasing from the book,
We believe that rules and processes serve several important functions.
However, like any living codebase, our rules and processes still contain bugs, inefficiencies, and room for improvement. Part of maintaining our team is identifying places where our processes are not working and fixing them. Don't hesitate to break a rule if it is preventing you from GSD, creating high quality applications, or working together as a team. Do make sure that if you break a rule or change a process, you do so thoughtfully and communicate with the rest of us about how we can improve.