Pub. Date:
Sustainable Software Development: An Agile Perspective / Edition 1

Sustainable Software Development: An Agile Perspective / Edition 1

by Kevin Tate, Jim Highsmith


Current price is , Original price is $49.99. You

Temporarily Out of Stock Online

Please check back later for updated availability.

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews

Sustainable Software Development: An Agile Perspective 4 out of 5 based on 0 ratings. 1 reviews.
Guest More than 1 year ago
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.