The Art of Agile Development

I think I will always enjoy books put out by O'Reilly. The Art of Agile Development is no exception. This book was thought provoking and fun. The authors, of which there were two, tried many different ways of transferring their knowledge. I really respect their use of narrative style; it keeps you guessing (there is role playing be forewarned!). The book is a nice overview of agile philosophies (most heavily in favor of XP) and makes no claim that it is the de facto. They even go so far as to stress that you are invited to break the rules that the book lays out -- Explaining that an agile developer is one that asks the question why and that they will forever pursue mastery. I had a couple of "ah ha!" moments thanks to these guys (James Shore & Shane Warden). Thanks gents!

I have no intention of writing a full review but I will say that this is a great book for whetting your appetite for agile techniques. It's also filled with a wealth of references to further study.

They open up a section on Simple Design with:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -- Antoine de Saint-Exupéry

Truly brilliant and a fantastic parallel to the topic! Love it!


I like the way they described TDD:

"Imagine TDD as a small, fast-spinning motor. It operates in a very short cycle that repeats over and over again. Every few minutes, this cycle ratchets your code forward a notch, providing code that -- although it may not be finished -- has been tested, designed, coded and is ready to check in."

If this sort of explanation is up your alley, then give the book a try, as it's what you can expect.

Lastly, I really appreciate that they pour in personal "in the trenches" examples. These help solidify the relevance of the various concepts.

A test is NOT a Unit Test when...

• It talks to a database


• It communicates across a network


• It touches the file system


• You have to do special things to your environment (such as editing config files) to run it

Tests that do these things are integration tests, not unit tests. [Shore & Warden 2007]

Collective Code Ownership

We are all responsible for high quality code. There is a metric for imposed risk by concentrating knowledge in just a few people's heads -- it's called the truck number. How many people can get hit by a truck before the project suffers irreparable harm? [Shore & Warden 2007]

Some developers consider this job security and, if you're in a company or state of mind where this is your sentiment, I sympathize with you. But it shouldn't be the case!

I often tell my clients that I only hire people that love what they do. My belief is that if you love what you do then your exuberance will be infectious and thus pollute the groundwater. You simply spend too many hours of your life "working" so why be unhappy while doing it? Honestly, if you can't stand your job, then you need to take action. That said...

As a team, we can't operate at 100% efficiency when we do not have redundancy. Things come up... Folks get sick, have emergencies, retire, go on vacations, you get the picture. Your project should not suffer when a team member can't make the game.

The concept of Collective Code Ownership (CCO) extends to all areas of development. When only one developer knows how to tweak the installer, it's time to refactor or educate.

CCO also applies to bug fixes... I know that I personally don't enjoy rooting around through broken code, especially when it's not my own! However, it's different when you weave it into your company culture. I subscribe to the old boyscout motto: Try and leave this world better than you found it.

Ideally, we don't have bugs because we're using TDD. But, let's be honest, we don't live in an ideal world and mistakes happen. I know that some of you would accuse me of rose color glasses syndrome but I assure you that this is not just Utopian dribble. It really works. That said, if you spend more than 15 minutes digging around and can't find the problem, it's probably time to rollback to the last working build.

[With CCO] No one person can be the bottleneck for change. [extremeprogramming.org]

Collective code ownership requires letting go of a little bit of ego. Rather than taking pride in your code, take pride in your team's code. [Shore & Warden 2007]

CCO is a tool. If it doesn't work for you, don't use it. My vote, always evolve. Don't scoff at a good idea because you'll never know if you don't at least try.

What does it mean to be done done?

If you ask the James Shore & Shane Warden, they'll tell you the following:

• Tested (all unit, integration, & customer tests finished)


• Coded (all code written)


• Designed (code refactored to the team's satisfaction)


• Integrated (the story works from end to end - typically, UI to database - and fits into the rest of the software)


• Builds (the build scripts include any new modules)


• Installs (the build script includes the story in the automated installer)


• Migrates (the build script updated database schema if necessary; the installer migrates data when appropriate)


• Reviewed (customers have reviewed the story and confirmed that it meets their expectations)


• Fixed (all known bugs have been fixed or scheduled as their own stories)


• Accepted (customers agree that the story is finished)

Can you run down this checklist at the close of an iteration and be certain that you've satisfied each bullet? If not, it's time to knock off a couple of the stories that you've committed to and focus on doing it right the first time.