Sustainable Software Development An Agile Perspective Oct 2005

Sustainable Software Development An Agile Perspective Oct 2005
by Kevin Tate

Download Book

If you are the author or the publisher, and would like to link to your site here, please contact us.

About Book

From the Back Cover

"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 sceneâ€”the 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

About the Author

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.

Excerpt. © Reprinted by permission. All rights reserved.
Sustainable Software Development: An Agile Perspective

Sustainable Software Development: An Agile Perspective

Introduction

When I was a computer science undergrad in university, I received a coffee mug for Christmas. You may have seen this mug, it has a number of tongue-in-cheek expressions and quotes about software development and software programmers on it. Here's a random sampling:

If a program is useless, it will have to be documented.

If a program is useful, it will have to be changed.

The value of a program is proportional to the weight of its output.

Any program will expand to fill any available memory.

Program complexity grows until it exceeds the capability of the programmer to maintain it.

Hare's law of large programs: Inside every large program is a small program struggling to get out.

A carelessly planned project takes three times longer to complete than expected; a carefully planned project will take only twice as long.

You get the idea....My mug is copyright 1980 by Art 101 Ltd., and I find it interesting that most of the sayings on this mug have stood the test of time, apart from one that mentions "job control cards" and an antiquated list of programming languages such as JCL, Algol, and PL/1. However, one saying on this mug still stands out to me today:

Weinberg's Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

I freely confess that this particular saying really gets my ire up. Perhaps I'm overly sensitized. I've had people quote it to me on a number of occasions; in particular, a former boss who felt that software developers lacked professionalism (he of course was a professional engineer and had the ring to prove it). Certainly what Weinberg says has a kernel of truth to it—that software developers can be a sloppy lot. But, by stating it as a law crafted as a negative statement, it implies that programmers can't write good software and don't pay attention to architecture, and that builders do. This is a slight to professional programmers, on the one hand, while being overly generous to builders on the other.

I am a big believer in the power of metaphor, especially in the context of technology. Sometimes, when faced with a highly technical term or feature to develop, it is incredibly valuable to use a metaphor that ties the term or feature into the real world through a simple comparison that everyone can understand. This is used in Extreme Programming, not to mention in many other technical fields such as usability analysis.

My real objection to Weinberg's Law is that it implies that a valid metaphor for software development is architectural engineering (i.e., building a building). It is astonishing how many people, from users to managers to software developers, believe this is a valid metaphor for software development when asked. Certainly, it is tempting to think that software is like building a building, and frankly what software developer, team leader, or manager wouldn't want to use the inspiration of Frank Lloyd Wright or the Sears tower in Chicago as a metaphor for his or her work? Well-architected buildings are certainly interesting to look at, and exceptional buildings help define cities.

Figure I-1
These buildings show different architectural styles and through their style and aesthetics also demonstrate the temptation to use buildings as a metaphor for software development. Left image ©Kathy McCallum, right image ©Steve Lovegrove. Images from BigStockPhoto.com.

Why isn't building a building a valid metaphor for software development? The short answer to this question is that buildings are largely static and software is not. Buildings are very expensive to modify after they have been built, and indeed the entire process used to design and construct the building is intended to maximize the chances that the building will meet the customer's requirements and will, within some margin of error, stay within the desired budget. It's easy to identify when a building is complete, but successful software never is. Software is cheap to modify, and any successful piece of software is virtually guaranteed to change over its lifetime. Actually, the software industry has trained its users into believing that major modifications are possible, if not inevitable and expected.

Good software developers realize that their programs can be modified to add just about any unanticipated feature—of course, there are limits. Changing a web browser into a database or a scientific visualization application into a word processor might involve huge rewrites, but the key thing is that good software programs with good developers can do just about anything they want. "It's only software" is a common mantra.

Buildings, on the other hand, are another matter. Ask an architect to make an unanticipated change and chances are she'll reply that the only recourse is to tear the building down and start over. Ask an architect to design a building that will handle all the likely configurations and he'll refuse the project. This is because there are only a limited number of possible changes the architect and customers can make to the building over time. In software, unanticipated features are highly likely because software is developed in a highly complex, hard to understand, technical, and constantly evolving environment. After five years of use and modification, the source code for a successful software program is often completely unrecognizable from its original form, while a successful building after five years is virtually untouched.

These differences alone should be enough to convince you that software is not like "building a building" at all. And yet, the methodology taught in school to software developers, the methodology used in most software companies, and the methodology described in the bulk of today's software literature is exactly the same basic methodology, that is, used in building construction and other forms of engineering; the so-called "waterfall" method, which advocates thoroughly understanding user requirements before designing the software, followed by coding, and then testing.

I don't mean to imply that the waterfall method is plain wrong. Great works of engineering such as buildings, airplanes, bridges, and ships have been built with this method. And many of the practices introduced in the waterfall method are good. The problem as I see it is that too few people question the methods they are taught in school and the workplace. This is a human trait more than anything else and not a reflection on software developers in particular. It's just that probably the majority of projects would be better off using a more appropriate metaphor for software development.

If building a building is not a valid metaphor for software development, then what is? My favorite metaphor for software development is a coral reef. I think good software like Adobe's Photoshop, Oracle, SAP, Linux, and Microsoft Windows creates an entire ecosystem of customers, plug-in developers, distributors, VARs (Value Added Resellers), service and consulting firms, hardware manufacturers, and even competitors. This software ecosystem is like a coral reef.

A successful software product plays the role of the underlying coral in the reef. The coral is what makes the entire ecosystem possible. None of the other organisms can survive without it. And just like software, a coral reef is continually evolving, growing, and changing (though, of course, at a different pace!). It's not just the reef itself that is changing, it's the entire ecosystem with all its dependent fish, invertebrates (sponges, fans, etc.) that change and evolve together. The reef ecosystem is incredibly complex, yet also fragile and vulnerable, just as a software product's ecosystem is prone to disruptive technologies or competition. This level of complexity, growth, constant change, evolution, and vulnerability I believe accurately portrays the complex world that tod...

Comments

SEND A COMMENT

PLEASE READ: All comments must be approved before appearing in the thread; time and space constraints prevent all comments from appearing. We will only approve comments that are directly related to the article, use appropriate language and are not attacking the comments of others.