TITLE: Agile Moments AUTHOR: Eugene Wallingford DATE: February 16, 2005 11:18 AM DESC: When I read about agile software development, and write programs, and discuss ideas with colleagues, I sometimes have moments that make think, "Yes!" ----- BODY: When I taught a course on Agile Software Development last semester, I fell into a habit of beginning the first class each week with a segment called "Agile Moments". Think of Saturday Night Live's old Deep Thoughts, by Jack Handy, only on a more serious plane. I'd gather up one or two interesting ideas I'd encountered in the previous week from posts to the XP mailing list, blogs I'd read, or projects I was working on. Then I'd pull out a provocative or entertaining quote and use that to launch into a discussion of the idea with my students. This seemed like a good way to share topical information with my students while showing them that they could enter into real conversations about how to write programs. It also reminded my students that I am always reading what others are writing about agile software, and that they could, too. Anyway, I've been so busy planning for ChiliPLoP 2005, for which I am program chair and a Hot Topic leader, and SIGCSE 2005, at which I am co-leading a workshop with Joe Bergin, that I haven't been writing a lot here. But I do find myself having Agile Moments, so let me share them with you. Programming and Testing Patrick Logan has a nice article on speaking in objects, which suggests that programming is best thought of as a dialog with the computer. The pithy quote that stands out in this article is one he attributes to Ward Cunningham:
It's all talk until the tests run.
We all know that's true. Simple Design Grady Booch is spending a lot of time in his considerable library as hew works on his Handbook of Software Architecture. Yesterday he wrote about one of his favorite books, John Gall's Systemantics. Based on Grady's recommendation, I just picked this book up from our library. Among other things, Gall argues that successful large systems invariably come from successful small systems. This reminds me of agile development's emphasis on piecemeal growth and evolutionary design through tests and refactoring. One of Gall's quotes captures one of the primary motivations of the agile approaches:
Bad design can rarely be overcome by more design, whether good or bad.
This points out the big risk of Big Design Up Front: If we get it wrong, we likely have sunk our project. It is hard to recover from a bad design. Of course, in true Agile Moments fashion, I also encountered a cautionary tale about evolutionary design. Martin Fowler warns of the risks of Abundant Mutation, which can occur with large teams when many sub-teams attack a common issue in different ways, or with smaller teams when a stream of newcomers continually join a project in mid-stream and take unfinished code in different directions. Martin reminds us that "evolutionary design requires attention, skill, and leadership". Continuous Refactoring Blaine Buxton recently posted a quote worthy of being an agile slogan:
Code removed is code earned.
Refactoring may end up shrinking the size of your system, but it is a net addition in the quality of your system. You earn the ability to add the next requirement more easily, as well as the ability to understand the program more easily. Blaine's quote reminded me of my favorite quote about the joys of refactoring, which showed up in a blog entry I wrote long ago:
The only thing better than a 1000-line of code weekend is a minus 1000-line of code weekend.

-- Brian Foote

Brian could make a fine living as a writer of slogans and jingles! -----