"Over the years I have seen the software development pendulum swing from one extreme to the other, as deficiencies in 'best practices' at one end of the spectrum spawned a new set of 'best practices' at the opposite end. Kevin Tate's book has finally brought the pendulum to a screeching halt, right about dead center. This book provides a balanced and practical guide to what's important if your goal is to develop software that lasts."
Mary Poppendieck, Poppendieck.LLC. Author of "Lean Software Development"
"1) In this very practical and accessible book interspersed with real-world examples and personal opinions, Kevin has distilled his years of developing quality software into a set of principles and practices that have been proven to work. If you are thinking of introducing an agile development environment (ADE) into your organization or of improving the one you already have, this book will help you clearly understand the benefits of a sustainable ADE, establish the practices to make it happen and coach you through the follow-up required to change the culture of your organization to make sure the changes take hold.
I am currently faced with exactly this challenge and this book has already given me several ideas I am looking forward to trying out.
2) In an industry plagued with missed deadlines despite long overtime hours, this book offers a refreshing alternative: a set of guiding principles and simple practices to follow that allow you to get the job done by working smarter, not harder. Drawing on the author's extensive experience developing quality software, the book clearly explains the principles behind a sustainable agile development environment, why it works, the practices to make it happen and the follow through required to turn these practices into habits."
Peter Schoeler, Technical Director, Artificial Mind & Movement
"It's a familiar scenethe schedule's tight, people are putting in heroic efforts to get everything done, then at the last minute a change request comes in that wipes out the gains you had finally managed to make in meeting your ship date. Looks like it's pizza at your desk for the weekend again! An unfortunate situation to be in but a pattern that repeats itself all too often. "Sustainable Software Development" offers hope to break this cycle. It shows how a change in mindset can free you from the tyranny of unrealistic expectations and brings development realities out onto the table for everyone to see. By following these techniques you will be able to define and manage a software development environment that will work for the long haul."
Kevin Picott
Software development for immediate success and long-term sustainability
Sustainable Software Development brings together principles and practices for building software that is technically superior, delivers exceptional business value, and can evolve rapidly to reflect any change to your business or technical environment.
Kevin Tate shows how to eliminate practices that make development unsustainable and replaces these practices with a sustainable approach that draws on the best ideas from both agile and conventional development. Tate demonstrates how to balance rapid releases and long-term sustainability, achieving both rich functionality and superior quality. You'll learn how to build a development organization that is more productive and can continually improve its capability to handle complexity and change.
Writing for developers, architects, project leaders, and other software team members, Tate shows how to:
Take control of your development environment, so you can outship your competitors, leveraging new technologies and responding to new business opportunities
Maintain a consistent pace that optimally balances short- versus long-term requirements
Keep your code base in a "near-shippable" state between releases
Prevent defects, rather than just recognizing and fixing them
Invest continually and cost-effectively in software design improvements
Leverage the fundamentals of the craft of software development
Integrate sustainable processes with Agile and traditional methodologies
© Copyright Pearson Education. All rights reserved.
Kevin Tate is a Chief Product Architect at Alias Systems Corp, a leading innovator in 3D computer graphics software, custom development, and training solutions for the film and video, games, web, interactive media, automotive, industrial design, education, and visualization markets. At Alias, his role encompasses development methodology, product architecture, and technology strategy. He had more than 20 years' experience in the software development industry. Kevin is a dedicated cyclist, canoeist, and lover of the outdoors. He lives in Toronto, Canada with his wife and two children.
Product Details
Would you like to update product info or give feedback on images?
|
|
Share your thoughts with other customers:
|
||||||||||||||||||||||
|
Most Helpful Customer Reviews
13 of 14 people found the following review helpful:
4.0 out of 5 stars
The End of the Sixty-Hour Week?,
This review is from: Sustainable Software Development: An Agile Perspective (Paperback)
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.
7 of 7 people found the following review helpful:
4.0 out of 5 stars
don't use architecture as a metaphor for software design,
By
This review is from: Sustainable Software Development: An Agile Perspective (Paperback)
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.
1 of 1 people found the following review helpful:
4.0 out of 5 stars
A good read for any developer,
By David Ward (California) - See all my reviews
This review is from: Sustainable Software Development: An Agile Perspective (Paperback)
"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.
Share your thoughts with other customers: Create your own review
|
|
Tags Customers Associate with This Product(What's this?)Click on a tag to find related items, discussions, and people.
|
|
This product's forum
Active discussions in related forums
Search Customer Discussions
|
Related forums
|