Sustainable Software Development: An Agile Perspective

"Sustainable Software Development" provides an excellent presentation of the principles and practices required to achieve a consistently high level of productivity in an agile environment. The material presented in this book supports two important concepts of agile development according to the author; building adaptable teams and building adaptable products. The author makes a very good argument early that all software development activity should be in support of producing a quality product. From design, to implementation, to testing, and deployment all activities should focus on developing a working product at all stages with the goal of preventing defects. All developers would like to believe their practices are focus on producing a quality, defect-free, product. Yet, all to often, regardless of intent or belief, the reality is that development activities may not be contributing to producing a quality product. Kevin starts with explaining the advantages of sustainable software development using several analogies. The fundamental concept is by adopting good development principles and practices, a synergistic effect will be produced and enable even greater development capacity with the additional effect of reducing defects. The second chapter is devoted to defining unsustainable software development and its causes. First understanding the causes of unsustainable development sets the stage for the discussion of sustainable development. The author argues that to achieve sustainability and organization must understand the stresses that promote unsustainable development and make appropriate adjustments to their practices. In chapter 3 the notion that principles are more important than practices with respect to achieving sustainable development. The author suggests that having a set of principles that guide the activities of development naturally leads to a set of best practices. The author concludes this chapter claiming that mindset and culture are more important than practices. The fourth chapter presents a simple concept that the product should always be in a working state. It should never be broken and always be ready for delivery. Maintaining a working product throughout a release cycle is key to maintaining sustained development. This also leads to a reduction in defects because many defects are detected during development before the product is delivered to the customer. The author presents 12 practices that will contribute to maintaining a working product. Continuous integration, nightly builds, coding standards and guidelines, and standards adoption are just four of the principles. Each of the 12 principles alone can improve product quality for any development team, but together they provide a multiplying effect that can catapult a development team from mediocrity to excellence. Defect prevention is the topic of chapter 5. In a traditional development environment the focus is on defect detection, essentially find

This is one of the best books I've bought on this subject. It provides no nonsense advice and gives clear guidance from an extremely experienced engineer. I regularly refer to the book during my work week. Good stuff!

Perhaps the single best point made in this book is in the Introduction. As a programmer, you are probably aware (actually you SHOULD be aware) of what design patterns are, even if you don't know too many of them. Famously, these grew out of observations made in architecture, that there are a few very common design patterns in modern buildings and city planning. It has been found in programming that design patterns are indeed a key observation. But an unfortunate consequence was that architectural design is also taken to be a good metaphor for software design. Many programmers believe this. Tate certainly believes that metaphors are vital for understanding software. But the metaphor of architecture is a dreadful choice. A building is fixed, after it is completed. Very difficult to make significant structural changes. Often, if pushed, one has to demolish the building and start over. Yet software is commonly asked to be continually changed. Certainly, this is true of successful, widely used code. The peril of the architecture metaphor is that believing in it elides one into a monolithic waterfall approach to software design. The waterfall is now widely recognised as badly flawed. Even if you take nothing else from this book, the above is well worth your time in understanding the limits of metaphor. While it sounds like an abstract literary finesse, using the wrong metaphor can lead to a bad design process. The bulk of the text has many suggestions about designing and programming, in the expectation that the code will have to be continually modified. Without getting too close to Extreme Programming, which has many detractors of its own. One suggestion is that the long hours put in by a team is not necessarily a sign of strength. A team might occasionally do this, to meet a deadline. But too often can be a symptom of misdesign and mismanagement. As well as lowering the productivity of the group. Another suggestion is simply to fix all bugs as soon as they are known. Before going on to add new functionality. This helps you maintain a stable base, and prevents the number of bugs from exploding. There are more suggestions. Most, like those above, have been known for decades. The book is a useful collection of these.

A powerful pick indeed. Kevin Tate's SUSTAINABLE SOFTWARE DEVELOPMENT: AN AGILE PERSPECTIVE blends basic software-building ideas and practices as they relate to the business environment, showing how to maintain a consistent pace, keep code base in readiness between releases, and prevent defects rather than doing damage control after. Chapters advocate flexibility, using ready tools for analysis, and understanding routines and approaches which encourage backlogs and poor releases.

The whole field of computer programming is only about fifty years old, the notion of organized programming dates back only twenty or thirty years, and those years have been crammed with a succession of software development methodologies, each of which would definitively fix "the software productivity problem." Some worked a little, some worked poorly, and some were disasters, but they all had one thing in common: in they end they relied on making programmers work harder and harder to achieve whatever gains they promised. They were all the equivalent of telling the drummer on the Roman galley to pick up the pace a little. But now comes a sea change: one of the cornerstones of agile development methodologies is that programmers are humans, have a life outside the cubicle, and can't work sixty-hour weeks for months on end without breaking down. Agile tells programmers and managers alike: "This is a marathon, not a sprint: you'll accomplish more if you set a pace that you can keep up for year after year after year." And the programmers and managers reply, "That's a great philosophy, and we like to hear it, but specifically what should we do to implement it?" And here, mostbooks on agile development fall silent. The exception is Sustainable Software Development: An Agile Perspective, by Kevin Tate (Addison-Wesley, 2006), which describes the functioning of a software development organization that can achieve high productivity for very long periods of time, while energizing the programmers. Mr. Tate starts by reviewing the current state of the practice, which is unsustainable because it tends to burn programmers out before products ship. He reviews all the factors that can contribute to the project from hell: poor leadership, unstable requirements, late integration, and so on. None of this will come as a surprise to anyone with experience in the field, but it's nice to see it summarized. Now he shifts to the principles of sustainable development, and I was ready to read the usual set of vague platitudes. But the title of his first section made me sit up: "Why Principles are More Important Than Practices." The argument of this chapter (which he carries through the rest of the book) is that the recipes for agile development are all well and good, but if you don't understand what you're doing and why you're doing it, you're not likely to do it well. Hooray! I think that's the first time I've heard that sentiment expressed so succinctly - at least in print. The principles he lists are common to most agile development: maintaining a working product, continuous integration, the importance of refactoring, and so on - but he casts them in the context of sustainability, and that makes all the difference. And finally, he follows with the practices themselves, and he is remarkably detailed in his treatment. He lists the usual practices of user teams, pair programming, and the rest, but he also talks about the importance of choosing the right tools, and of g