Noel Rappin Writes Here

Previously on Locally Sourced: About a year ago, I started this newsletter with a bunch of posts that I originally called XP 2020 and later called Entropy Essays – you can find all the posts here. I got bogged down and never got to the punchline… There’s a common thread in the story of how testing, object design, and pair programming have been adapted since XP and Agile became buzzwords. I think estimating fits here as well.

Trying to Define Undefinable Terms: The Locally Sourced Story Previously on Locally Sourced: I’ve been writing about XP and Agile. Most recently, pair programming. And how I think about technical decisions. I started to write a different essay here, but then I realized that I was sort of depending on having written something like this. So I wrote this. I’ve been writing all these posts about Agile and XP methods and I’ve been talking about process and about trust, but I haven’t defined them in the way I use them and I haven’t talked about how I think they are related.

We hope that 1 + 1 = 3 Previously on Locally Sourced: I’ve been doing a lot of these oddly titled posts about XP and Agile practices. Like testing. Or OO. I wrote about inclusion on agile teams. And about team metrics. Next up: pair programming. And even though it sounds a little pretentious to my ears, I really do think this is going somewhere, and I think between the last one and this one, the shape of the argument is starting to make sense to me.

Or Why is a Software Team Like A Shortstop Previously on Locally Sourced: I’ve been writing these Entropy Essays about Agile and XP practices. Here’s the most recent one. You can see the rest here. Tell all your friends and colleagues to subscribe. One of the great things about writing this newsletter is that it’s forced me to think some ideas through in more structured ways than I might have if I was just talking to myself in my own head.

Or: Trust Goes Every Which Way, And Makes Agile Work Previously on Locally Sourced: I attempted to justify all this agile stuff. Before that, more agile stuff. Also, I have a book out, and good marketing practices would suggest I mention that from time to time. This time around, I’m worried that all these words won’t help make the central point: Everybody on a software team should feel included and safe in their work because it’s the right thing to do.

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.

Who doesn’t love a taxonomy? Previously on Locally Sourced: We talked about test speed, and we asked why you hired that test? If you like this kind of thing, tell a friend or colleague. One thing that I see a lot in online discussion of programming styles is the idea that Object-Oriented Programming is just one thing that you either do, or don’t do. I think that’s reductive, and not just because different languages encourage different structures in objects.

Previously On Locally Sourced: The Entropy Essays are a series of essays about how programming practices inspired by Extreme Programming such as testing, pair programing, and object-oriented design play out on modern web projects. The first one was about test speed. And eventually we’ll get to why they are called Entropy Essays. I want you to stop for a second and think: “why are you writing this test?” Not “why are you writing tests in general?

Speed matters. But not precisely. There are only two things that matter when thinking about the speed of your automated tests: How fast can you run the relevant set of tests to let the tests be helpful in development? How fast can you run a complete, green build for deploy? We’re talking about the first one in this essay. In development, you want to be able to run the tests you are writing and a subset of tests that are most likely to break based on your changes.