Noel Rappin Writes Here

I mean, really…

Previously on Locally Sourced: I wrote about an XP practice. Then I wrote about it some more. Then I wrote about a different XP practice. Then I wrote about it some more. (Okay, it’s a bit of a stretch, but a domain metaphor was an XP practice, and OO modeling went hand in hand.) In any case, with more about Agile and XP coming up, I thought it was time for some self-justification. Which is always a little dangerous, so I hope this doesn’t sound whiny.

I’ve been writing and planning this whole series of Entropy Essays, the whole point of which is to talk about how practices that come to us from Extreme Programming have changed over time and how they do and don’t match the way I see teams work now. It’s part “back to the future” and part “this doesn’t work and we should stop doing it”.

Share

Subscribe now

But I think that before I go any further, I want to explain why this is important to me, why I’m spending my energy on this esoteric process stuff when I could be talking about my favorite editor or teaching about Ruby 2.7 features or something…

Or, to be honest, why I’m writing about programmer job satisfaction given, you know, the world. I honestly don’t know if I have a good answer for that. Or at least one that wouldn’t sound self-serving.

The first part of the answer is that XP and Agile have taken over my corner of web development, at least linguistically. It’s been nearly 15 years since I worked on a team that didn’t use some variation on the terms “story”, “velocity”, and “iteration”, that didn’t at least aspire to pair programming and automated testing, and that tried to avoid doing big design up front. And yet, I think a lot of how these teams approach their work doesn’t feel like a team as described in the early XP/Agile literature — to be clear, sometimes this is for good reason, some of the early stuff was unworkable, not inclusive, or otherwise didn’t travel well. I think the difference between the vocabulary and the original use of these terms is interesting.

The second part of the answer is that I believe long-term developer happiness and satisfaction are related to team process and structure more than the tool stack or the problem space. The XP/Agile practices are a framework for good team practices that I think is not perfect, but is widespread, and at least “good enough to criticize” and which, in my head, is pointed in the direction that I want my teams to go. I think that better developer process leads to more empowered teams and that, again in the goal state in my head, leads to more of a voice for everyone, especially people who often don’t feel they have a voice. (I know it doesn’t often work that way in practice, I’m interested in trying to talk through why that is, and see what can be salvaged, what must be improved, and what should be tossed aside.)

The third part of the answers is a story. I’ll just sketch it here, I’m pretty sure we’ll get more of it over time.

In Spring 2000, I burned out as hard as I ever have.

I was coming off my first project that was large enough to have a team, and small as it was (five people, four months), it was way beyond the scope of what anybody involved with it had ever done. The leadership (myself included) while well-meaning, was lacking experience and knowledge. We made every mistake you could imagine, and a few you couldn’t, and it was so far away from programming as I had enjoyed it as a student that it seemed like I’d never find a way out. I felt like I had no control over what happened, that the project had just spun out unavoidably.

The Extreme Programming Explained book had been out for about six months or so, and I had heard a lot of things about it ranging from “This will save us” to “this is the worst thing to ever happen to programming”. (I can’t remember where I would have read about it, though. Blogs weren’t really a thing, so I’m assuming some combination of mailing lists, or more likely, USENET newsgroups.)

I read the book coming off this terrible project. And boy, did it make an impression. Not only did it talk about testing, which became somewhat important to my career, it was also about putting decision power in the daily experience of developers. Maybe most important to me in that moment, it was about sustainable pace – 40 hour work week is an explicit part of the original set of practices. I remember reading the section on sustainable pace out loud at a retrospective meeting to my CEO/Project manager while other developers kind of teased me for of course being the person who would bring a book to a meeting. Which, true enough.

More to the point, XP was my first introduction to the idea that you could change the day-to-day practices of a team deliberately and in ways that would make the team happier and the work easier. This project is the source of my career-long aversion to “exciting” software development. Later, the same kind of emphasis on developer happiness is what would eventually lead me to Ruby and Rails. These ideas are very important to how I think about development teams.

And look, I know there are problems with XP and Agile, we’re going to talk about some of them in more detail. There are hidden assumptions about who has authority, and who feels safe to offer opinions. Some of the practices don’t really apply to all teams, and there’s never been good guidance about how to manage that. The whole set of practices is hard to implement, and not very resilient to halfway measures or to picking and choosing. It’s hard to say that your team methodology is both made up of a set of self-reinforcing practices that need to be done together and also that each team needs to find the practices that work for them.

And yet. Flawed as XP is, the emphasis on sustainable process, on developer flexibility, on making large problems into small problems, on reducing complexity, these all seem like the right direction. It’s professionally important to me that I work on teams that are sustainable and satisfying. It’s personally important to me that these teams make all their members feel in control, and that the projects for the next five years make better choices that the last five years, as I think we currently make better choices than we did five years ago.

So, that’s why I care. And it may be a small thing in the world, but it’s a thing that I think I can help make better.

That wasn’t so bad, was it?

Next time: Agile and communication. Next week: Not sure yet, possibly pair programming.