« SOA Papers | Main | Scott Sterling tweaks JDepend »

Agile Software Development: review

I spent last year eagerly anticipating reading Robert Martin's Agile Software Development. Uncle Bob as he's known, has been a long time evangelist for Object Oriented programming, Patterns and more recently, Extreme Programming. Indeed he's successfully converted his business around XP; the next time someone tells you XP doesn't cut it commercially, point them at http://www.objectmentor.com.

We'll begin by saying that this will be an initially controversial text that will become a classic, one of less than a dozen texts in the last ten years worthy of the term, such as Design Patterns, Refactoring, Programming Pearls, and Effective C++. At 500 pages it looks unthreatening but this is an information rich book that will require more than one sitting. It's not an on the job book, or a howto guide. Instead it's very much one you will read and savour with a cup of cocoa or a good single malt, and reread over the years. It's rare that we point to a technical book these days and say that. Bob Martin recommends certain paths through ASD depending on who you are. No matter, I recommend starting with Jack Reeves' essay in appendix D, it will set the tone for the rest of the book.

ASD is a concrete, unapologetically technical book of great breadth, depth and enormous wisdom. It's chock full of code, case studies, objects, patterns and hard-won experience. Woven throughout is the emphasis on agile practices such as unit testing, refactoring, continuous integration and managing the reality of changing requirements. All this plus chapters on UML and managing code releases. What's most delightful about ASD is the absence of posture and mindless evangelism that accompanies software methodologies. You come away with sense that everything in this book is here because it works, not because it's supposed to work. One area where the book is uncompromising is that the purpose of a software project is to only ever deliver a working software system as defined by the customer. Delivering such software and only such software is what defines a successful project - everything else is secondary to code. Those steeped in traditional SoftEng methodologies and the variations tailored for enterprise and federation class projects found in the big services organisations and corporate IT departments, where resisting requirements change, paper deliverables and the overall process are highly valued will have trouble with this premise. Even if you are comfortable and happy with high ornament approaches, this book is still worth reading for its insights into developing OO systems alone (it's probably going to become an authoritative work on OO), and finally if only to see how the other half live. Another less stringent viewpoint is in Bob Martin's take on OO itself. To him, OO is primarily a technique for manging dependencies in software. He's held this view for as long as I can remember, but those who think of OO as an analysis and modelling paradigm may find it a little strange.

ASD is a treasure trove for any developer, but it will be especially useful and enlightening for three types of folk. First the ex-technical who have either moved into purely architectural or consultative roles, or have become engineering VPs, and need or want to get in touch with cutting edge development practices. Make no mistake, this is the direction software development is going to take over the decade, and this book perhaps better than any other in print will explain agile development and how it works to manage change in your terms. Second, developers who have a good grasp of OO and Pattern based programming but maybe can't square agile techniques with the popular emphasis on upfront design & architecture, requirements lockdown and generally being expected to see around corners. If this is your working environment and you can't adopt agility wholesale, or you find the agile mindset alien, ASD will help you both cherrypick, then articulate. Third and most unusually, it will benefit those who have already been using agile methods for some time but aren't sure how software design, and particulary design patterns and UML are supposed to work with these methods, particulary XP and SCRUM. ASD will help find a balance.

What's not to like? The one part I didn't like was the tale of two companies- it's been floating around the XP community for a few years now and most people there think it's hillarious (oddly I've come to find it tasteless, although I don't know anyone that shares this view). Thankfully it's tucked away in an appendix. What's missing is the chapter that tells us how agility deals with legacy systems, in particular databases. In fairness not just the agile movement, but the industry as a whole still isn't sure how to splice new code with the old. Nonetheless working with legacy systems is increasingly the norm today as organizations seek to keep IT costs down and justify expenditure by maximising what they already have. It's also true that legacy systems, being invariably difficult to test and integrate against, are where agile approaches can logjam.

January 2, 2003 07:57 PM


James Strachan
(January 3, 2003 10:29 AM #)

I think you're link to the book is wrong; it seems to point to a Python book. You might wanna change your link.

Zohar Melamed
(January 3, 2003 12:29 PM #)

I share your sentiments regarding the tale of two companies. It serves the same purpose as the old saying 'it's better being healthy and rich then sick and poor'. Life is very rarely lived in such clear contrasts, and the story is rather childish and silly.

Bill de hra
(January 3, 2003 06:10 PM #)

Gah, fixed it. Thanks James.

Trackback Pings

TrackBack URL for this entry: