Stephen Freeman Rotating Header Image

October, 2009:

Friday 13th, Talking at Skills Matter

Prove you’re not superstitious! I’ll be giving my talk on Sustainable TDD at Skills Matter on Friday, 13th November. Sign up here (if you dare).

This talk is about the qualities we look for in test code that keep the development “habitable.” We want to make sure the tests pull their weight by making them expressive, so that we can tell what’s important when we read them and when they fail, and by making sure they don’t become a maintenance drag themselves. We need to apply as much care and attention to the tests as we do to the production code, although the coding styles may differ. Difficulty in testing might imply that we need to change our test code, but often it’s a hint that our design ideas are wrong and that we ought to change the production code. In practice, these qualities are all related to and support each other. Test-driven development combines testing, specification, and design into one holistic activity.

I just ran it at the BBC and people seemed to like it.

If you miss this opportunity, you can always see it at QCon San Francisco.

QCon San Francisco


I’m running a track at QCon in San Francisco on Friday 20th November. The topic is Technical Skills for Agile Development, and it’s about some of the technical essentials that Agile teams need to keep moving.

I’ll be presenting a session, based on material from our book, on how to live with your tests over the long term.

See you there?

Test-Driven Development is not an elite technique.

This “Darwinian” post that TDD Is Not For the Weak says that not everyone can cope with TDD, it’s for “the Alpha, the strong, the experienced”. I don’t want to believe this, because I think that developers who can’t cope with any level of TDD shouldn’t be coding at all, so I won’t.

This claim has been made for every technical innovation I’ve seen so far (objects, event-driven programming, etc, etc). Sometimes it’s true, but most of the time it’s about what people are used to. Michael Feathers pointed out a while ago that the Ruby community is happily exploiting techniques such as meta-programming that were traditionally regarded as needing a safe pair of hands. What’s changed is that a generation has grown up with meta-programming and doesn’t regard it as problematic. Of course, there will be a degradation in understanding as an idea rolls out beyond its originators, but there’s still some value that gets through.

Sure there’s a role for people to help the generation that is struggling to pick up a new technique, but that doesn’t mean that TDD itself will always be beyond the range of mortal developers.

A Mugged Liberal

A Liberal is a Conservative Who Hasn’t Been Mugged

I discover that our book Growing Object-Oriented Software, Guided by Tests is already up with the file sharers. This is before Nat and I have even seen a printed copy. I don’t know whether to be flattered that someone thinks our effort is worth pinching or annoyed that the production process has not protected our interests.

If you’ve downloaded a copy, remember that it took us three years to write, which includes a great deal of lost income. The least you can do is tell the world how good it is so that maybe we sell a few more copies.

Do do XP

In this post, Tobias Mayer argues against doing Extreme Programming (XP). I have a lot of time for Tobias, but I think he’s wrong on this one. I don’t know who he’s been talking to, but some of this is “strawman” argument, and I’d be more likely to be convinced if Tobias had tried XP just the once. XP is not a universal solution, but it is one possible choice and we know how to make it work.

As an occasional XP advocate, I don’t “blame Scrum for the lack of good development practices in the software industry”, I blame the software industry. If we worked in an effective industry, we wouldn’t be having methodology wars because things would just work. Now this same industry is messing up Scrum too by just taking on its ceremonial aspects. On the other hand, to blame XP for blocking good practice is just bizarre.

XP is a tiny movement that attracted some attention. What XP (version 1) did achieve was to show that it is possible to break through the logjam of cautious procrastination that still cripples many development teams, but without resorting to hackery. It gave teams a reliable package of practices that just worked. Of course XP didn’t take over the world because it’s not suitable for everyone–not least because it requires a degree of focus and skill that is not appropriate for many teams. Kent Beck’s presentation of XP version 1 was extreme on purpose: it was designed to inspire us huddled masses, and to stretch the boundaries of what was considered possible in software development, to reframe the discussion.

I think Tobias has forgotten just how far we’ve come in the last decade. That we have a craft movement at all is because XP put the actual writing of code back into the centre of the discussion–just look at who’s involved, it’s the same people. He also forgets just how counter-intuitive many of the XP practices are, especially compared to the direction the industry was moving at the time.

Tobias writes that the good development practices were spreading slowly at the time, but I’d argue that without XP we’d still be waiting. Test-Driven Development is still not that widely accepted and even the original C3 team didn’t adopt it fully until Kent was writing his book. Refactoring had a small academic following, but it’s not very safe without the compensating practice of TDD. I suspect most teams still ban changing code unless it’s to change a feature. Pair programming is still a very hard sell and, again, works much better in the context of TDD. I’ve seen enough Scrum teams that have not found a coherent set of technical practices. To say that they just need to improve their Scrum implementation begs the question of how Scrum is adopted and the limits of self-organisation.

Some final nit-picks. There are two editions of the XP book, the second is more recent than 12 years and has a “softer” approach to the methodology. As for the relevancy of the practices, the C3 project worked in an environment (Smalltalk/Gemstone) that still outclasses what most of us use today. Much of the work in the XP community has been to try to recreate that flexibility in inadequate current technical environments. What’s really scary is how slowly this industry moves.

Software Nightmares (2)

About a month ago, Michael Feathers wrote another post that cited Gordon Ramsey. That reminded me to follow up my earlier post with observations from a couple of episodes from UK series 4 that make the point (thanks Channel 4).

First up is a curry restaurant in Nottingham (which has no shortage of competition) opened by an ex-sales manager and glossed up to look like an ’80s night club. Being from sales, his view is that the customers gets what they ask for, so he’s offering design-your-own curries—whatever combination you want. The result is that the kitchen brigade (who are good) can’t cope with the variety and turn everything to mush. When Ramsey has them cook all hundred-odd dishes on the menu, the waiting staff can’t tell which is which.

The owner sees the process as simple order-taking. Offer the customers whatever they ask for, regardless of the effects on the demoralised staff and low quality. It turns out that the customers aren’t curry experts and don’t like what they’re getting, so the restaurant is losing money. Ramsey’s solution is to cut the menu back to something the brigade can do well, and to offer what the customers what they actually want.

Second up is a carvery outside London that’s been bought by Scott, an ex-IT consultant. It’s losing money so, in an attempt to fill the place, he’s offering two-for-ones at below cost price; the only people who put up with the dreadful food are pensioners. He’s hired a cheap brigade who can’t even cope with the grill idea that Ramsey proposes, and the kitchen is so decrepit that Ramsey has it condemned. Scott is discovering that reducing costs isn’t working and risks poisoning the clientele.

Scott seems most comfortable in the office behind a computer, presumably planning the work that everyone will do. He appears to be the only owner in any of the series that has no interest in food or customers—the value part of the equation. He has no idea if his people are competent or what constitutes good service.

Back-to-back, the episodes make a nice pair. To belabour the point, we can’t do good, valuable work when the process is one-sided: when requirements are forced through an organisation without thought for the consequences, or when work is driven from behind the scenes without enough attention to a paying customer.

It should be obvious, but we need reminding. Hands up if you work in one of these places.