Given a vision and desire to achieve sustainable software development, the following principles apply:
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.