malvasia bianca

Probably the most important hour I spent while I was transitioning out of teaching and into programming was spent attending a talk on extreme programming. Ever since then, the XP approach has been my default way of thinking about how to produce software; I’ve never been on a team doing XP, but I’ve dived headfirst into most of the practices. Still, I attended that talk twelve years ago, and I’ve got a lot more experience now than I do then; what do I think about the XP practices these days?

Of course, the XP practices don’t come out of nowhere: XP has values and principles as well. The values are Communication, Simplicity, Feedback, and Courage; hard to argue with that, but they’re also a bit general for me to say much about them. The principles are more interesting to me: Rapid Feedback, Assume Simplicity, Incremental Change, Embracing Change, and Quality Work. I could probably still write a post about each of those, and I keep on coming back to Incremental Change in particular, but they’re all super important to me in really concrete ways.

So the principles are a huge part of what makes XP important to me: but equally important is the concrete guidance that the practices give. Their guidance was particularly important when I was getting started; what do I think about them now?

 

The Planning Game

This is a funny one. It’s a big part of Scrum, a methodology which dominates discussions of agile; and wow, it’s really usually not done seriously. There’s this ceremony around estimating and committing to what will be in a release: but estimating is super hard, commitment is a serious word to throw around, and I just don’t see either of those treated the way I’d like.

The thing is, though: I think not treating estimating seriously is the right choice, I would just prefer to be up front about that. The Kanban focus on figuring out what to do next makes a lot more sense to me: how often does it really matter exactly how much you’ll get done in the next week or two or four? And, if you’re going to treat commitments seriously in a fixed iteration context, then either you’re a lot better estimator than I am (and I’m actually pretty good) or you’ll need to sandbag; I don’t like either of those choices.

I learned a lot from thinking about the Planning Game and trying it out. But still: not my favorite practice any more.

Small Releases

Another funny one, again partly because of its appearance in Scrum. A lot of Scrum teams seem to gravitate towards four weeks; in some contexts, that probably seems like very small releases, but it seems way too big to me. But once you start pushing it to one week, it gets a lot more interesting.

And, of course, it gets even more interesting once you push smaller than that: it starts raising the the question of whether discrete releases even makes sense. These days, I think that moving towards continuous deployment is better; small releases are a good stepping stone, but only a stepping stone.

But there’s another way in which I move away from small releases in the opposite direction. Part of the XP idea (at least as I see it) of small releases is that your released code is Done Done. But no matter how good you are at testing whether your code matches your intention, code isn’t Done Done until you’ve seen how customers react to it and you’ve adapted accordingly. Also, as somebody who works on backends of distributed systems: I wish I were better at predicting complex system behavior via tests, but I also think that some aspects of how they’ll behave in production are difficult to understand in advance.

Metaphor

Do you understand this? I don’t.

Simple Design

Now we’re getting good. Do the simplest thing that could possibly work; follow the four rules of simple design. Some people like to plan details of their design in advance, and there are many such people whom I have a lot of respect for; but I really like slicing design down into small chunks, and the guidance XP gives in that guard.

Testing

I was surprised that the principle is simply “Testing”, not “Test-Driven Development”: they’ve always been very closely linked in my mind. At least just calling it Testing has the advantage that you shouldn’t restrict yourself to unit testing. At any rate: I love TDD, and I strongly support testing more broadly even though my brain is less attuned to other forms of testing.

And I’ve always had coworkers who thought TDD sounded like a good idea; I’m generally furthest along the TDD spectrum at any job, but it’s always the case that unit tests are there when I show up and that many of my coworkers think honest-to-god TDD (as opposed to just writing unit tests at some point in the process) is a good idea. Which isn’t something I necessarily would have predicted, and maybe I’ve just gotten lucky with my coworkers, but it makes me happy.

Refactoring

Another practice that I love. It’s the mathematician in me: the desire for elegance, and the desire to get from place A to place B via a series of small, well-defined steps. (That’s something I like about TDD, too!)

Refactoring is something that gets talked about a lot at jobs I’ve been at, too, but in a much less precise way: people say “refactoring” when they mean “cleaning up the code”. That’s important, of course, but it loses something without the discipline of Fowler-style refactoring. But even there I see good things: a bunch of my coworkers are in the habit of generating pull requests that are best reviewed commit by commit, which gets at the heart of this benefit. (And which applies to situations where you’re changing behavior, too!)

Pair Programming

I just don’t know about this one. It mostly makes sense to me; I’ve basically enjoyed it when I’ve done it; but I still don’t seek it out. I’d be interested in working at a place that really is devoted to pair programming, especially if it’s part of the full XP package (and especially if the team pairs Belshee-style), but I won’t particularly shed a tear if I don’t have that experience.

My current job does at least have a quite good code review culture, and actually my previous job did as well. So that’s something. It’s probably a sign of my arrogance that I wasn’t big initially in pushing for code reviews, but now I like them a lot.

Collective Ownership

I love this one: I’m a very nosy person. And, just as I’m surprised how much interest in TDD I see, I’m equally surprised at how rarely I see collective ownership. It seems like startups (and maybe larger companies, for all I know) like silos, and frequently continue to like them quite a lot even after I’m there. (Though I have had some successes in breaking down silos, too.)

My view of this is getting more nuanced, though, because getting collective ownership to work right is linked with having small teams with clear boundaries. In the past, I haven’t always pushed for small teams, but now I appreciate them more; but I’m still not very good at figuring out exactly what those boundaries should be like, or how to make the boundaries work well with getting as much business value as possible.

Continuous Integration

This is a slightly funny one to see called out: not quite as much of a basic ground rule as, say, version control, but still. Though there are still subtleties here that I don’t understand how to work out well, especially on largish projects with lots of modules.

40-Hour Week

I think it’s a good idea. I’m not sure how much of that is for humane reasons and how much of that is for effectiveness reasons; I would like to focus more on making those 40 hours as high quality as possible.

On-Site Customer

This feels to me like it’s morphed into a business/engineering split, without the assumption that the business side is an actual customer. Which, on the balance, I think is a good thing: it seems to me to devalue the art of product development if you assume that being a customer is the key attribute to being good at picking stories to work on.

I’ve seen that split done well at Playdom; in other places I’ve been, product people haven’t been integrated into the teams.

Coding Standards

Part of me wants to treat this as the same sort of “well, duh” attitude as Continuous Integration, but I think there’s still a decent size contingent of people who don’t see the point of this one. My attitude has always been “what’s the point of not doing this one?”; fortunately, teams that I’ve been on have agreed. Still, it seems a bit out of place these days as a basic practice: if you’re doing Pair Programming or even just Collective Ownership, then of course you’ll adopt Coding Standards.

 

Good stuff; it generally holds up quite well fourteen years later. But there are also questions that I would ask or directions that I would move in a post-XP world, and in in a world of evolving distributed systems. In particular, I have questions around planning, iterations, and the question of being done: what are the benefits of iterations, and are iterations the best ways of getting those benefits? I like slicing things down into small chunks, I like prioritizing those chunks, and I like having a notion of what it means to be done with those chunks; I’m much more dubious about the idea of grouping and synchronizing those chunks, or of estimating how many chunks you’ll fit into a period of time. So the Kanban approach of focusing on prioritization makes more sense to me.

And, as I said above, I’m more dubious about the notion of a definition of Done than I used to be. The underlying assumption there is that you can you can predict in advance how code will behave in production, and I don’t believe that you can reliably predict either how customers will react to code changes or how large distributed systems will react to code changes. (Though there’s more scope for the latter than the former.) So I’d rather embrace that uncertainty, structuring code pushes as experiments; that means focusing on learning after the code push, and on making the code push as resilient as possible in the face of surprises. Those are important enough that I’d like an approach that calls those questions out explicitly, which requires a richer (and at least a two-phase) notion of Done.

There are other details about the practices that I’m not sure about: e.g. these days Continuous Deployment seems more interesting to think about than Continuous Integration. But if I step back one level, the XP Principles remain as rock-solid an inspiration as ever. Rapid Feedback; Assume Simplicity; Incremental Change; Embracing Change; Quality Work: I love all of those. And I imagine that if I come back a decade or two later, I’ll still find those principles motivating me.