Today through noon Friday I’m at the internal Sun Engineering Conference. We opened with a couple of speeches on XP and Agile Software Development by Ron Jeffries and John Nolan. I think there were some people in the audience who weren’t quite convinced, but I learned a couple of things.
Ron made one of those points which is obvious once you see it (except for I hadn’t): writing tests after you’ve written the code is boring and painful: writing them first (a key premise of XP) makes it more interesting, and thus less likely that you’ll skip them.
The second point, which I’m sure must be in all the XP scripture but I seem to have missed it, is that feature-at-a-time development makes development project schedules immensely more predictable. It turns out that the time it takes to build the tests for, implement, and debug a feature averages out nicely, so on the basis of just a little experience, you can compute how long there is to go as a function of the number of outstanding features. Predictability is A Good Thing.
Finally, Ron noted that XP tends to squash out the difference between development and maintenance modes: once you’ve built the first feature, you’re in maintenance mode forever.
Push-Back · Someone asked: “If you’re building an Operating System, what’s that first feature that you build, test, and deliver?” Which was a surrogate for the real question: “Is this stuff gonna work for us here at Sun?”
You have to acknowledge—and Ron did—that building Operating Systems and the Java Platform is different from pulling together a loan-pricing or ticket-selling application. But in fact, the traditional Big Cycle of software development (Conception, Planning, Development, Customer Tests) is, as Ron pointed out, simply wrong.
And this highlights one of the key points about XP that I think its advocates (including me) have internalized so much that we forget to highlight. Here it is: detailed specification, in advance, of the functions of a large software system is essentially impossible. As I wrote here:
This work has reinforced my conviction that you never really understand the problem until you’ve written some of the code. We’d worked out in advance how this thing I’m writing was supposed to interface to the rest of the system, then on day three I had to go back and say “This isn’t gonna work, here’s why” and we made some changes.
I assume there must be people out there who are smart enough to spec out an interface without having written any code and get it right; but I also assume that they’re few and far between, and normal people like you and me shouldn’t count on this sort of virtuosity.
The same point—that you don’t really understand a feature until you’ve implemented the tests and the code—is illustrated here and here.
XP deals with this cleanly: you operate one feature at a time, and you don’t try to pretend that you’re so smart that you can design everything so you won’t have to refactor as you go along.
Extreme Morale Problems · John Logan’s talk, based on five years of experience with Agile Development methods, turned up a problem that hadn’t occurred to me: the XP approach can be bad for morale. It’s all about discipline and progress one small, deterministic step at a time; there’s not much room for heroism or cowboy behavior in general. Do this for a couple of years in a row and you’re apt to end up feeling seriously ground down.
Yes, you get higher-quality results and you don’t have schedule meltdowns, but you still have morale problems. I’ve never encountered this because I am rarely in heads-down development mode for more than a few months at a time, and I often work in solo mode.
John offered a bunch of practical tips for how to work around this, for example “Gold Card” rewards that allow developers off the XP feature treadmill with time for creativity and experimentation. He also suggested more customer face time for the developers and more group time for the whole team for “Show and Tell” and process tuning.
But I bet there’s more work to be done in this space, and it’s worth doing, because getting good outcomes is an awfully strong motivator.
