Why Principles Are More Important Than Practices

The difference between principles and practices is analogous to the difference between vision and features in a project. Unsuccessful projects start by defining a set of features that when put together are surmised to meet some user need. These projects are technology looking for a market, and the odds of their success are low. Successful projects, on the other hand, start with a clear user need and a vision of how to meet that need. The vision is simple and can be used to develop an initial set of features and a prototype that can be put in front of customers for feedback. The feedback is used to refine the feature set, which is then put in front of customers for more feedback, and so on. This is iterative development, as it is called in agile software development. The following are key aspects in the vision-oriented approach to product development:

• A user need and vision so it is clear what is being built

• Rapid refinement to adapt to change

• A close relationship with users so they can provide timely feedback

• Continual learning to refine the product so it best meets user needs while avoiding unnecessary features

Too many people are looking for a magic set of rules or list of practices that define the silver bullet of software development. Our education and upbringing reinforce this desire by using rules and step-by-step procedures to help us solve problems. We run into trouble, however, because we rarely recognize the role of complexity in the application of rules. Rules work best when the problem is simple but break down as complexity increases. But software development, and product development in general, is not simple.

In sustainable software development, the principles are like vision and the practices are like features. Principles define what you want to accomplish and the practices how you want to go about it. Too much of the mantra in software development is around sets of practices. We hear "follow this set of practices" or "if you aren't following these practices, you aren't using this technique." If only it were that simple! These practice-oriented approaches put the cart before the horse by defining the features before the vision. While there is no doubt that in every case the practices are valuable and can be learned from, if you don't know what you are trying to achieve, then your efforts are going to be misdirected.

The problem with practices and rules in the face of complexity, as in software development, is that it is too easy (and human) to lose sight of where you are going and what you want to accomplish, get bogged down in the details, and flail around. The most common response to flailing around is to apply bureaucracy, to define a set of strict rules and milestones that cannot be deviated from. But bureaucracy stifles innovation and is most often misguided, leading to unintended side effects. It is also inflexible and change-intolerant.

Some practice-oriented approaches provide a simple set of practices that are intended to lead to sustainable development. But, by stating their approach as a set of hard-and-fast rules, they mislead people into believing they are complete, when in fact they are not. Good teams apply these practices and can achieve success, but the chance of failure is still high because of the complexities inherent in software development and the people who develop it. Also, by stating that the practices must be adhered to, a different sort of bureaucracy or elitism develops where people say silly things like: "I won't work more than 40 hours this week because that is one of our practices," even though there is a critical deadline in the near future, or "We never design aspects of our architecture because we only design what we need today," even though it is plainly obvious that a bit of extra work today would make tomorrow's work, that everyone recognizes needs to be done, an order of magnitude easier.

Great teams recognize that what they are trying to achieve is more important than how they achieve it. They listen to the practices that are proposed to them, ask questions to understand what they are trying to accomplish, and then apply them as needed. Great teams see through the strict rule-based façade and are successful because they see rules as a solid foundation to build on. They work from a clear user need (high user value through features and high quality) and a vision (the principles) and continually learn and refine their approach (the practices) as their project progresses. This is what underlies sustainable development. To summarize, there are three elements to sustainable development:

• A vision and set of guiding principles ^[1] that define what needs to be accomplished.

  ^[1] see chapter 6 for a description of guiding principles.

• Practices that are consistent with the principles. The practices outlined in this book are not a set of rules. Instead, they are intended as building blocks that your team should refine and add to over time through continual improvement of your approach to software development.

• A tight feedback loop of experimentation, learning, and refinement so that during the development of the project the project team is able to change, modify, and enhance their practices as required so the team can best fulfill the principles (vision).