Applying the Principles of Sustainable Development

Given a vision and desire to achieve sustainable software development, the following principles apply:

• Continual refinement of the product and project practices.

• A working product at all times.

• A continual investment in and emphasis on design.

• Valuing defect prevention over defect detection.

Each of these seemingly arbitrary principles contributes to sustainability. Since the rest of this book outlines practices that support these principles, let's examine each principle in turn.

Continual Refinement of the Product and Project Practices

Continual refinement is a recurring theme in sustainable development. Software is complex and must evolve continuously over a long period of time in the face of changing user requirements and an evolving ecosystem of markets, partners, technologies, and competition. At the start of any project it is impossible to plan for all the required changes. Therefore, teams must plan for change and implement practices that enhance their ability to change. These practices must cover how they manage their projects, how they design their products, and also the practices used to develop the products themselves. To accommodate these changes, teams need user involvement and an emphasis on reflection, learning, and experimentation but also lightweight practices to keep themselves on track and monitor progress and risks.

Continual refinement is required for sustainable development because it defines a set of practices that establish a heartbeat for a project. This heartbeat establishes a steady rhythm that is used to keep the project going and continually monitor progress in a lightweight way.

A Working Product at All Times

A software product should always be in a working state. This doesn't mean it is always functionally complete, just that it works and has high quality. The longer the product is not working, the greater the chance that quality is degrading every working minute, and the greater the cost to get the software working again before completing the project. The goal of software teams is to ship their products, and by keeping a product in a state as close as possible to being shippable, the easier it will be to ship.

A secondary meaning to this principle is that the emphasis of the team is on producing a working product and shipping it, not on producing documentation of user requirements, software designs, etc. that might lead to a product. This is a key principle of agile development: The best way to get user feedback is to give users something they can really comment on, a product that is written to fit their needs even if it is only work in progress. Documentation, even if carefully reviewed, does not elicit the same quality of feedback as something that users can actually use. Even prototypes are better than a document.

A working product is required for sustainable development because it ensures that time is spent on productive activities. Effort spent getting the product back to a working state is wasted effort and a missed opportunity to be doing valuable work.

A Continual Emphasis on Design

Design is a key differentiator between products. Both good design and bad design are immediately obvious and can heavily influence purchasing decisions, but the most important aspect of design quality in terms of sustainable development is on the productivity of the development team. Design decisions and changes are made every day and by every member of the team, and the team needs to allow itself to make design changes as appropriate throughout the project. Traditional software development emphasizes trying to design the software to anticipate every possible future use at the beginning of the project or prior to the writing of any code. This does not work. Agile software development advocates designing only what you need today while not making silly decisions that close the door on future enhancements. Contrary to what some people believe, agile development actually requires a lot of design, perhaps even more than traditional approaches.

A continual emphasis on design is required for sustainable development because good design and sustainable design practices extend the life of the product by keeping the implementation in a healthy state that enhances maintainability and changeability while ensuring there is a simple long-term design vision.

Valuing Defect Prevention over Defect Detection

Defect detection involves trying to find and fix defects after changes have been merged into the production software. Defect prevention, on the other hand, emphasizes catching defects before the changes are merged into the production software.

The key symptoms of a defect detection culture are an undue reliance on defect tracking systems, manual testing efforts, and large numbers of defects that reach customers.

In the typical defect detection organization, organizations invest a great deal in a QA or testing organization. They have elaborate defect tracking systems in which members of the organization spend countless hours sorting, prioritizing, and assigning defects for fixing. And yet regressions (defects fixed or features introduced in previous versions of the product which no longer work) are still introduced in new product versions as features are added and bug fixes are made. The quality onus is primarily on QA and testers, and in many organizations a virtual wall is constructed between developers and QA. Developers produce new versions of the software, and then throw it over the wall to QA, who test it and then accept or reject it. The software may take weeks or months in QA before the product is ready to ship to customers.

In a defect prevention culture, defect-tracking systems are still required, but their importance is greatly reduced. This is due to much lower defect counts because development teams have multiple safeguards in place to ensure that regressions are never (or rarely) introduced in already existing functionality and that new features and bug fixes are properly tested and have safeguards that ensure they will not break in the future. A heavy emphasis is placed on automated testing so that people (QA and testers) can focus on testing the product in a realistic manner, in ways that mirror what actual customers will do with the product. There are no virtual walls in a defect prevention culture because ideally the testers are part of the team, and the quality onus is spread evenly between the developers and QA and testers.

An emphasis on defect prevention is required for sustainable development to ensure the development team is highly efficient and is putting its effort into creating value for the customer, not on wasted effort. Also, by minimizing the number of defects that reach customers, development teams are able to have productive conversations with users about features and workflow because users are able to use the product in realistic ways.

Striving for Sustainable Development Is Like Juggling

I like to use the metaphor of juggling when explaining sustainable software development. Striving for sustainable development is like juggling the six balls shown in Figure 3-1. Think of the entire team juggling together, like many minds controlling one pair of arms and hands.

Figure 3-1. Software development is like juggling the four balls of sustainable development at the same time as the much larger balls that represent features and bugfixing. Instead of just juggling the two large balls, sustainable software development recognizes the genius of the AND and results in the ability to juggle all six balls at the same time, even though they are different sizes and weights.

The four small balls, each representing an element of sustainability, have a subtly different color, texture, and weight. If you drop one ball, you're still juggling but your outcome isn't going to be as good as it could be, and your audience (the customer) is definitely going to notice the mistake. Juggling demands you understand each ball, its shape, weight, color, and texture, and that you are able to focus on any one ball while keeping all four in focus.

The larger balls that represent features and bugfixing are completely different in shape and weight from the small balls. The complexity of the task of juggling the four small balls and two large balls usually leads teams to juggle only a few balls because that's much easier.

The team may juggle just the large balls. This leads either to the purely ad-hoc code-then-fix approach to software development or bureaucracy, consisting of milestones, rules, and mandatory documents. Unfortunately, these approaches ultimately lead to unsustainable development.

Or the team might juggle one or more of the small balls so they don't have to deal with the large balls. They'll produce awesome designs or have a working product or continually refactor their code, but they won't get anything done. And if they manage to ship and have customers, chances are the customers won't be satisfied.

Great software teams are able to juggle all six balls. They understand that juggling the small balls comes first because they are more predictable, and this makes the task of juggling the large balls much easier. This ability to accomplish the genius of the AND in the face of the tyranny of the OR leads to sustainable development while capturing the complexities required to do so.