Chapter 3. The Principles of Sustainable Software Development

In the traditional software organization, the emphasis in software development is on features, bug fixing, and the plan. Development proceeds in a linear fashion, beginning with analysis and design, the development of a plan, coding, testing, fixing of problems, careful tracking against the plan, and then use by customers.

This linear (waterfall) approach to software development is still the primary method of software development taught in schools. But this is an engineering approach to software development that isn't suited to software development as described in the Introduction.

At least part of the reason software firms are rarely able to achieve sustainability is because software developers do not receive an education that prepares them for the real world. In the real world of software development, software must be developed in a complex and changing ecosystem of technology, competitors, and customers. And it isn't until programmers are first exposed to the commercial world that the size of the code base they work on and the size of the teams they work in become significant. This is also the first time programmers have to write code and live with it for any meaningful length of time. Not just their code eitherwith personnel turnover there comes an increasingly large body of code that nobody on the current team wrote.

It's unrealistic to expect the education system to duplicate real-world conditions. This is because the education system needs to teach students their craft, which must be taught in a controlled environment so students aren't overwhelmed. But knowing a craft is only one part of what is needed. In order to provide a bridge from the academic to the practical worlds, we need a mindset that can be used to create a culture of software development. This should be the culture of sustainable development so that teams can achieve and sustain a high pace of development over the long term, despite all the surrounding complexity, without heroics. Otherwise, it's too easy to burn out on the profession.

Without the right mindset and culture, too many people try and fail with the methods they are taught. They then fall back on ad-hoc variants of the traditional linear approaches because the linearity provides a degree of comfort that progress is being made while also being familiar. But by being ad-hoc, there is either going to be too little structure (which is code-then-fix development) or too much, which applies too much bureaucracy in an attempt to keep the process under control. And bureaucracy tends to stifle innovation, flexibility, and change tolerancethe very properties that a dynamic and changing environment requires.

The bulk of this book, and most books on software development, are filled with practices and rules. Practices are too often treated as templates for success, when the reality is that practices must be tuned to the situation and team. And rules are a result of bureaucracy that is put in place to try to make software development more predictable. Predictability is often achieved, but at the cost of innovation and the ability to respond to customer requests. If your team implements a given set of practices but doesn't have the right mindset or culture that supports the practices, you're not going to get far. You will be better off than doing purely ad-hoc software development, where you will be good but not great.

Before your team talks about development practices you need to first focus on the principles you are going to follow. These principles should guide you every day in making tradeoffs and in fostering the right mindset and culture for your team and organization. The practices will follow from the principles you choose to adopt.