Stephen Freeman Rotating Header Image

August, 2005:

Miles Whitehead

Today I went to the funeral of Miles Whitehead, who died of cancer.

A lovely man, very funny and very bright. I wish I’d spent more time with him.

High and Mighty software processes

If your development process was a vehicle, what kind would it be?

h3. Delivering straight to production

At Agile2005, I led a workshop on “Delivering Value Early”:http://agile2005.org/track/workshops#WK2 We talked about the sort of organizational things that obstruct getting value out of a project incrementally, rather than waiting until the end (I still have the flip-chart sheets here waiting for me to type them in the conference wiki. Apologies). Later on we discussed tactics for increasing team effectiveness and some people talked about how they had offloaded tasks, such as deployment, from the development team to reduce their workload.

Kent Beck was in the session and he proposed an alternative, which is to make the team do _everything_ so that the feedback is as direct as possible. If someone else has to deploy, then the development team will never really feel the pain and fix the problems. He talked about one team which has become so good at delivery that they can release to production from the development desktop. No testing cycle, no staging environment, no sign-off; straight to production—and this is a serious mission-critical system. Obviously, it takes a while for a team to build up that kind of reliability and trust, they have a track record of near-zero errors in the live system. Think how fast they can go [1].

h3. High and Mighty

This reminded me of a Malcolm Gladwell “article”:http://www.gladwell.com/2004/2004_01_12_a_suv.html about the popularity of the S.U.V., based on Keith Bradsher’s book “High and Mighty”:http://www.amazon.com/exec/obidos/tg/detail/-/1586481231?v=glance. At a deep level, people _feel_ safe in S.U.V.s because of the high wheelbase, heavy frame, padded interiors, and even the cup-holders [2]. Unfortunately, the statistics prove the opposite: the high wheelbase increases the likelihood of rollovers, the heavy frame makes the vehicle more difficult to control, the padding isolates the driver from the outside world and, well, you shouldn’t be drinking hot coffee in traffic.

bq. The S.U.V. boom represents, then, a shift in how we conceive of safety—from active to passive. It’s what happens what a larger number of drivers conclude, consciously or otherwise, that the extra thirty feet that the [Chevrolet] TrailBlazer takes to come to a stop don’t really matter, that the tractor-trailer will hit them anyway, and that they are better off treating accidents as inevitable rather than avoidable.

The numbers are very clear, people are safer in small, nimble vehicles. They buy large S.U.V.s because they feel that the extra metal will protect them when they hit something, but it makes them much more likely to get into an accident in the first place.

bq. [Volkswagen] Jettas are safe because they make their drivers feel unsafe. S.U.V.s are unsafe because they make their drivers feel safe. That feeling of safety isn’t the solution; it’s the problem.

Big clunky vehicles break the feedback loop between driver and road.

h3. Another driving metaphor

So, to contort this story into a metaphor about software, do organisations take an S.U.V. approach to delivering software [3]? They put layers of indirection between the development team and the production box so they feel safe to release. They carry extra weight, such as change management processes, separate QA groups, formal reviews and sign-offs, to protect themselves from their own deliveries. But that extra weight causes other significant problems: it forces the organisation into large releases, so it’s hard to respond quickly and to understand what’s changed each time; it breaks the feedback loop between the development team and the system, so they can’t feel where the problems are and fix them; and it encourages a culture of passive safety, where people upstream in the process (including those deciding features) rely on people downstream to catch their mistakes.

Imagine instead, a development organisation that ran like Gladwell’s description of driving a [Porsche] Boxster;

bq. Standing still, the Boxster didn’t feel safe: I could have been sitting in a go-cart. But when I ran it through the handling course I felt that I was in perfect control. […] I steadied the Boxster at forty-five m.p.h. and ran it through the obstacle course. I could have balanced a teacup on my knee.


1. A measure of the sophistication of the team is that they don’t work on production code when they feel tired or burnt-out, they know it’s not worth it. I know of hardly any organizations that understand this.

2. Apparently this comes from very early childhood memories of being with your mother and being fed warm liquids. Really.

3. Actually, I suspect a great many organisations take a “derelict pick-up truck” approach to delivering software: bald tires, no brakes, and tired drivers.

Make extension points objects

In his most recent blog entry, Martin Fowler writes about the problems of requiring people to “call super”:http://martinfowler.com/bliki/CallSuper.html. Absolutely! He uses jUnit setup and teardown as an example of where this hurts, we had exactly that problem in “jMock”:http://www.jmock.org, which makes our version of TestCase difficult to integrate for other people who want to do the same thing for _their_ test frameworks. Java annotations might be an answer, but not for me since my current client is only just coming to terms with Java 1.4.

There’s another approach, as Ivan Moore pointed out, which is to “replace inheritance with composition”:http://ivan.truemesh.com/archives/000490.html. What if the event was handled by a separate object? If TestCase had been split like this:

public class TestCase
  Test test;
  public void runBare() throws Throwable {
    test.setUp();
    try {
      test.run();
    }
    finally {
      test.tearDown();
    }
  }
}

where Test is an interface that defines the events in a test’s lifecycle. Now we have two objects: one concerned with the safe running of a test, and one concerned with the body of the test. Both are now focussed on doing just one job, and I can wrap the Test object with a decorator if I want to extend its behaviour.

Maybe the rule of thumb here is that if you want to add an extension point to your code, then no half measures: make it an object.

On retrospectives

dilbert2005228910811.gif