Customer Reviews

Sustainable Software Development: An Agile Perspective

5 star:		(2)
4 star:		(5)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

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 good configuration management, and even of coding, documentation, and design standards. Because Mr Tate puts the practices in the context of the principles, it's always clear why the practice is important, how you would adapt it to your own organization, and when you might skip it altogether. Indeed, this section could stand alone as a "how to" book on agile implementation, better than most on the market.

They tell me that, in any review, you're supposed to find three things that could have done better. So, keeping in mind that I think this is a great book, here are my suggestions for improvement. First, the book doesn't really address the macro-level causes of unsustainable software development: the relentless, unreasonable pressure to be first to market with a product, no matter how flawed. It's true that programmers and managers can't influence that pressure, but the book would be better if Mr Tate at least explained the economics that drives the industry to such bad practices. Second, his definition of "culture" is too limited to be useful. I hesitate to fault the book, because a description of organizational culture is a rather large book in itself, but it would have been nice to see a discussion of degree of risk taking, or traditions of transparent decisions, or any of the other cultural factors that make agile development possible. And finally, the book tends to minimize the difficulty of making the change to a real agile environment. As many of us have learned, it takes months to introduce agile techniques into an organization, but it takes years to change the organization itself, and Mr Tate's treatment of change makes it sound entirely too easy. There, I've made my three suggestions for improvement, and now I'll remind the reader that they're relatively minor criticisms of a very good book.

The final appealing attribute of the book is that it speaks to the whole organization. Programmers will find material that helps them change their design and coding skills; managers will find new ways of planning, organizing, and allocating work; and executives will find strong arguments for adopting new, more effective, more sustainable software development policies, even in the face of the pressure to produce more and more with less and less.

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.

"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 finding and fixing the bugs, a code then fix approach. The author stresses that the focus should be on defect prevention, preventing defects by ruthless testing during the development process, the use of tools during development, pair programming and code reviews.

Chapter 6 is devoted to design and practices that support sustained development. In this chapter eight practices are presented. While some of the practices might be viewed as having an implementation focus, all have a direct affect of system design and the adaptability of the design. The practices cover design vision, guiding principals, and simplicity in design, refactoring, design patterns, frequent rapid design meetings, rearchitecture, and designing for reuse.

Chapter 7, "Continual Refinement", is about change with respect to the development team. The author sums up the purpose of this chapter in the first paragraph, "In order to achieve sustainable development, teams need a way to balance short-term requirements and long-term needs: to ship their product as soon as they can while accepting, anticipating, and even welcoming change."

The last chapter covers what is probably the most difficult aspect of creating sustainable development, "Culture Change and Sustained Development." This chapter is about introducing lasting change in a team or organization. While this chapter is not an extensive treatise of organization behavior, it does provide some insight into what needs to be considered to introduce change in a team or organization that will result in an organizational culture that promotes sustainable development.

This book should not be viewed as an instruction manual for establishing rules and procedures that will result in an team or organization that will achieve sustainable development. Rather than an instruction manual it should be seen as a signpost or guidebook that points you in the right direction, but it is up to you to make your way along the path.

Sustainable Software Development by Kevin Tate is a useful and much needed book. It doesn't provide any groundbreaking new ideas or practices, but it summarizes a series of good practices which lead to long term sustainable development. Sustainable development is a topic that needs a lot more coverage since, in the world of fast projects and tight deadlines, lots of teams fall in the trap of unsustainable development and piles of legacy.

The book basically consists of three parts (not marked in the book). The first three chapters are an introduction to the four main chapters of the book. Each chapter describing a principle. The last chapter is "the change chapter" that somehow everybody feels needs to be in a book.

The first part consist of describing sustainable development and makes an analogy between a proactive maintenance in a chemical plant, suggesting that similar things are needed in software development. It also has some on the much unnecessary quotes to Good to Great (which really annoyed me). The second chapter looks at causes of unsustainable development and it seemed to miss the dynamics of unrealistic customer promises, instead it just considers the results of this dynamics. But still, one of the best cause analysis on unsustainable development I've seen. The third chapter introduces the four principles: Working Product, Defect Prevention, Emphasis on Design and Continual Refinement.

The second part has a chapter based on each of the above principles. Every chapter introduces related practices. Like the Working Product chapter talks about not leaving defects in the product, continuous integration and topics like that. Most practices can be found in different modern software development literature, but Kevin provides quite a good summary. Every now and then he felt he should not be "too agile" and tried mixing ideas with traditional development. I do think the book failed in this. Anyways, still one of the best summary of agile practices.

The third part is "the change chapter" which every book on new practices needs to have. It didn't contain much new ideas, though, one slight difference is that Kevin doesn't say, like much of these lame change chapters, "Change needs to be planned and tracked carefully and managed... blah blah". Indeed he recognizes that you cannot really control a change like this. Great insight.

In general, I liked the book and it was well written. I disliked the up-front design wording from the author, though, I think we would agree on the real content. It seemed like he felt he had to stay between the agile movement and his earlier experiences.

In rating, I was doubting between three and four stars. Three because the book doesn't bring very much new ideas, though, four stars, its a much needed summary of agile practices. I decided on four stars because I really enjoyed the authors stories about his experiences. For me that made the book and for that purpose, I'd recommend reading it.

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!

Would you like to start practicing agile development without the "extreme-ism" of Extreme Programming (XP)? Sustainable Software Development: An Agile Perspective by Kevin Tate does a good job in its explanation without some of the emotional baggage that XP often encounters.

Contents: Sustainable Software Development; Unsustainable Software Development and its Causes; The Principles of Sustainable Software Development; Working Product; Defect Prevention; Emphasis on Design; Continual Refinement; Culture Change and Sustainable Development; Practice Summary; Extreme Programming and Sustainable Software Development; Sustainable Software Development and the CMM; Recommended Reading; Conclusion; References; Index

If you've studied any of the agile methodologies currently in vogue, you'll recognize most of the material in here. There's the emphasis on short iterations, fixing defects early and often, continuous builds, and so forth. What I liked most about this book however, was that it sounded much more "reasonable" than XP. XP can often come across as a "cult", where you have to take it all or nothing. That's not true, but for some it becomes a religious issue (like pair programming). Tate takes a more reasonable approach, outlining a complete program that will definitely lead to shorter development cycles and higher quality. But he also recognizes that it doesn't have to be an all-or-nothing approach, and that even minor steps can pay off with big dividends. The chapters from Working Product through Continual Refinement are broken up into a number of "Practices" that allow you to focus on one aspect of agile, sustainable development. Once you understand how that works and how it plays together with everything else, you can then put it into play in your environment. The Practice Summary chapter is a short summary of all the practices together, along with indicators next to each practice that is a keystone practice to making it all work. If you do nothing else, implementing the keystone practices will improve your development life by leaps and bounds...

While it may not be groundbreaking material, it's solid and workable. It's also packaged in such a way that you can start to implement lightweight methodologies without the preconceptions that XP often has (no documentation, no design, etc.). For the right audience, it's definitely a suggested title.

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.