XP Day Toronto 2007

XP Day provided me with a great deal of food for thought. Brian Marick gave an engaging keynote speech entitled, “Six Years Later: What the Agile Manifesto Left Out”. Deb Hartmann facilitated the Open Space, themed “What XP Projects Forget,” which produced interesting discussions throughout the day. J.B. Rainsberger gave a lively speech tying together theory, business terminology, and the XP approach.

The main focus of Brian Marick’s keynote was on the values behind the Agile Manifesto. The four values he discussed were skills, discipline, ease, and joy. The original authors of the manifesto were already quite skilled, so it probably seemed obvious at the time. As agile methodology spreads, people of a wide variety of skill levels are trying to apply the principles, with varying degrees of success. No methodology can get around the fact that a successful project requires some competent individuals to write, test, and deploy the code.

I would add that working in an agile environment also requires a great deal more interpersonal skill than solitary development, and this is rarely made a priority. Technical skills include refactoring and automated testing, ideally test-driven design. These skills require significant discipline, since they require work now to save pain later. Pairing and short iterations are effective at least in part because these practices enforce discipline.

In discussing ease, Marick compared a codebase to a home. Developers spend many (if not most) of their waking hours in the code, but few codebases are as “livable” as even a mediocre home. Marick used a number of examples to demonstrate desirable qualities of homes:

1. Homes are designed to support common activities
Consider the silverware drawer, which is frequently accessed in almost any home. The silverware drawer is always found in the kitchen, usually in one of the top drawers close to the sink. You could probably go into a random person’s home, and quickly find the silverware drawer. Once you’ve opened the silverware drawer, you see that it is organized in a predictable fashion. There is generally some kind of divided tray, with a section for each type of utensil: forks, spoons, and knives. All the silverware is accessible, organized, and available in a (relatively) standardized format.

2. Homes tend to place usability first
Consider a gas stove. The house probably already has a gas line in the basement, to supply the gas furnace. The most elegant design would be to put the gas stove in the basement beside the furnace so that the two appliances can share a gas line. This is preposterous, of course, since we need the stove in the kitchen for convenient food preparation.

3. Homes support tinkering
Suppose that until now, you haven’t cared about watching movies. Your interests are changing, however, and you decide you need a way to watch movies as a family. Marick described his “home entertainment center”: a laptop and some stereo speakers sitting on a lobster trap, set up in front of the couch. He was able to achieve the desired effect with materials he had on hand, and if he should become more serious about watching movies, he could easily upgrade part or all of his current setup.

I imagine that a codebase with these qualities would feel comfortable to the developers, perhaps even creating some sense of joy (the fourth value). The tools to do one’s job would be readily available, and common tasks would be well-supported. Coupling would be kept as low as possible, but components would still be available when needed. The code would support experimentation, with a reasonable path from experiment to feature. The code would also be comprehensible to new developers within a reasonable time frame.

These qualities would tend to produce workable code, i.e. code that can be worked as a potter works clay. Note that clay has enough structure not to collapse into an amorphous mass, but is still amenable to change. These ideas about desirable code qualities are not new, but I did find the home metaphor to be a useful way of framing the problem.

Jason covered much of J.B.’s speech in his previous post, so I have only a few points to add:

  1. Maintainability can be thought of as the cost to add a new feature. Minimizing the cost increases maintainability.
  2. The decision about whether to invest in production or production capacity is really a business decision, but in software development the business people rarely have sufficient information to make that decision.
  3. You owe it to yourself to increase your own production capacity; in fact, your career depends on it. There is often an expectation that this will happen on your own time, but a much more humane approach is to devote some of your regular working hours to learning new skills, technologies, etc. A good company will seek to invest in people in this way.
  4. Inventory and throughput are indistinguishable until the code has actually been delivered into the hands of real users.
  5. One element of successful projects is respecting the business/technical split, such that each side fishes in their own waters.

Quotes from XP Day:

“Business people often don’t care that much about business value.” — Brian Marick

“The view from the top is just as confusing as the view from the bottom.”

“Systems understanding is no substitute for effective leadership.”

“You can refactor code a lot more easily than you can refactor users.”

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply