Steve Freeman

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

Delivering straight to production

At Agile2005, I led a workshop on Delivering Value Early 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].

High and Mighty

This reminded me of a Malcolm Gladwell article about the popularity of the S.U.V., based on Keith Bradsher’s book High and Mighty. 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.

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.

[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.

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;

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.