Engaging, Clear, and Concise

Kent Beck’s Test-Driven Development by Example is the next best thing to pair-programming with a master of his craft.

I’ve never met Kent, but I have to imagine the book is written how he speaks — because no one would write it that way if they didn’t. I’ve never encountered a more conversational book, replete with digressions, arguments with himself, tangents, and bad jokes. This doesn’t distract from the content, but instead creates authenticity. The first two sections of the book are extended examples, and written in that voice they built the sense in my head that Kent was less an author and more a person. That meant that when he switched from the descriptive to the prescriptive in part three, I took his rules as things he had learned from his experience, rather than as wisdom delivered from the mountaintop.

Speaking of part three, the question-answer form that he uses in laying out his patterns for TDD is one of the most effective ways of communicating these kinds of ideas I’ve seen. An example:

One Step Test
Which test should you pick next from the Test List? One that will teach you something and that you are confident you can implement.

This is followed by two or three paragraphs explaining the rationale for the guideline. I found this problem-solution-explanation format solves an issue that faces so many authors: How to design a text so that it can serve both as a tutorial and as a reference.

To do both of these things in a book so short is a masterstroke.

Slicing It Thinner and Thinner

Part of my plan right now is to take all of the things I’ve decided are important and take at least one step forward on each of them every day. That means when I get busy, I don’t just drop two or three and work on the others. It means I have to find ways to take smaller steps so I can fit them all in. It’s challenging, but I’m finding it very satisfying. I can’t fit two half-hour tasks in but I have time for one? I have to find a way to make fifteen minutes on each of them worthwhile. And that’s really the trick: Learning to see how I can make tangible progress in smaller and smaller chunks of time.

I’m sure that my Agile experience has nothing at all to do with this…

Listen and Change

I should stop being surprised by how much my training as an actor and an improviser is useful beyond performance. Today’s epiphany was about feedback.

As an actor, you have to learn to take the note. This was hammered home to me during my sophomore year in college. After one of the last rehearsals before our play opened, the assistant director was giving me feedback on some lines I had fumbled. I was working through them, and in the process I was explaining why I’d messed them up. The director — my friend Rob — looked at me and said, “Paul. Take the note.” And I got it. The AD wasn’t asking me questions, so no answers were required. He was telling what I needed to fix, and my commentary on why I’d done what I had didn’t matter to that. I stopped talking, acknowledged the input, and next rehearsal I fixed it.

Sometimes, when we get feedback on something we’ve done, we don’t always want to take the note. When someone says, “Could it do this instead?” our instinct is to say that would be hard, or to say that they shouldn’t want it to do that, or any of many other variations on “no” that use more words than that. We don’t really listen to what they’re saying because we’ve become defensive and feel the need to justify what we’ve done. Fortunately, there’s way out of this.

First, take the note. Listen to what they’ve said and what concern it expresses. Why are they asking for this change to the feature? What’s at stake here for them? They wouldn’t bring it up if it didn’t matter to them, so your first job is to figure out what’s important here. It’s not about you at this point, so don’t just wait for your turn to talk — listen.

Then, do what a good improviser would do and ask “How could I say yes to this?” The reason you’re getting this feedback is because the person giving it to you perceives a gap between what is present and what is needed. Feedback systems exist to close that gap. That means that we have to be open to changing based on feedback. If not, we’re running in open-loop control.

Saying yes can be hard, of course. Maybe there’s a powerful reason why you can’t do exactly what they’re asking for. If so, see if you can propose an alternative that captures the essence of the concern they’re raised. Maybe you think what they’re asking for is a bad idea. In that case, you really need to figure out their perspective, because you probably don’t have the same understanding of the situation. Dig deeper into the reasons for their request, being open to the possibility that that there’s something you don’t know that makes their position make sense. And maybe you just don’t know how to get around what’s preventing you from giving them what they want. In that case, collaborate on a solution with them. Tell them, “I’d like to find a way to do that for you. I’ve got these problems that I’m not sure how to deal with. Can you help me work through them?” You may not always be able to get to yes together, but you have to try.

In order for feedback systems to work, we have to (a) listen to the information we’re getting, and (b) act on that information to change the situation. These can be hard things to do, but a simple place to start is by taking the note and considering how to to say yes.

In The Beginner's Mind There Are Many Possibilities...

I sent out this paper to my team at work this week. I already believed in a some of the ideas it, but the data and (even-to-me counterintuitive) results that it presents surprised me. I’m now very curious to see if we can replicate them, and at the very least, it’s got me thinking about we decide who works on what in a very different way.

Update

Fitness: 100 Ups (Minor) + 100 Hundred Pushups, Week 1, Day 2 (6-8-6-6-12)

Link Roundup for 29 October 2011

I’ve accumulated a backlog of software engineering-related links, so it’s time to burn some of them down.

• Elisabeth Hendrickson explains why everyone on the team needs to test.
• Rands challenges managers to take The Rands Test.
• Derrick Bailey illustrates Bob Martin’s SOLID development principles with motivational posters.
• Lyssa Adkins reminds coaches that it’s hardly ever “them.”
• Stephan Roock offers five tips for improving how your Scrum teams deal with impediments.

Update

Fitness: Rest day