Obvious comment of the day – TDD makes Pair Programming easier

A fairly obvious observation hit me today…

If you are trying to pair program without also doing test driven development, when do you change roles? When doing TDD with Pairing, there is a rhythm to when the roles switch – see Micro Pairing. But if you’re not doing TDD, the person typing is frequently lost in solving a fairly large problem, they are balancing a bunch of things in their heads, and they have to finish a big thought before they could possibly swap the keyboard with their pair. So, while the typer is solving these big problems, what does the other person do? Just sit there? It just seems pretty painful…

I’m sure its not impossible, but it sure seems like TDD is a near necessity for Pair Programming.

Thoughts?

— bab

Continuing the Growing up Geek Meme

I’ve been tagged by Brad Wilson to tell a bit about my geek childhood. Like most of you, I certainly had one 🙂

My earliest geek memories starts with watching Star Trek back in about 1972. It was Return of the Archons – the one where the zombies in robes wander around talking about “Being of the Body”. I remember being totally and completely fascinated by it, and being hooked on science fiction from that point on. That led me to finding the Heinlein juveniles, like Space Cadet, The Rolling Stones, Double Star, Citizen of the Galaxy and so on. I can honestly say that Heinlein’s attitudes about politics, religion, and life, as well as Spock’s general logical demeanor, were a huge influence on me back when I was somewhere near 10 or a bit younger.

A few years later, I learned about amateur radio somehow. I think it was a year or two before we moved from Des Moines, IA to St. Louis, MO. I remember buying The Amateur Radio Handbook, a highly technical book that was years too old for me — I must have been about 8 at the time. I wanted to get my ham license right then, immediately, so I started studying. Of course, electronic theory was a big part of the test, so I had to learn about stuff like Ohm’s Law. The only problem was that it kind of required algebra, and at 9, I hadn’t really learned that yet. So my 4th grade teachers, Mrs. Clark and Ms. Dean, sent me to the 5th grade teacher for algebra tutoring. I did finally get my license a couple of years later, after moving to St. Louis. A couple helpful hams in town taught me the last few bits I needed, including letting me practice Morse Code, and I passed my General test when I was 10 or 11. I was now WD0FDG 🙂 Over the next couple of years, I studied for the highest class license, the Amateur Extra, taking the test a couple of times, only to fail. On my last attempt, I missed the last two questions on the exam, pushing me over the limit by 1. Had I passed, I would have been one of the 10 youngest Extra class licensees in the country at that point 🙁

After that, I spent a lot of my time reading Heinlein’s more mature novels, talking on my radio, playing with electronics, playing violin, and other exciting activities for an early-teen boy.

I eventually did find sports and girls a few years later, but some things never change… I haven’t been on the radio on years, but I know I’ll get back to it some day. I did pick up amateur astronomy a few years ago, a similarly geeky habit, still read Heinlein religiously, if you’ll excuse the expression, and still watch Star Trek in all its forms. And now there is this computer thing that seems to eat up so much of my time 🙂

Well, that is the geek story of me. Hmmm, I guess I should tag a couple of other folks now… How about Cory Foy, Ade Miller, and Michael Feathers

(I’ll update this post with a picture of me as a kid once I get home!)

— bab

A Story Splitting Story

This is a true story from a true client I’m working with . The names and details have been changed to protect the innocent…

Story splitting

Several of us were attending a pre-sprint planning meeting yesterday, trying to flesh out the user stories that the product owner was planning to bring to sprint planning in a few days. They are still pretty early in their agile adoption as well as their technology adoption, so there are lots of questions floating around about process and tools.

A story came up in the meeting that described the interaction that a user would take when visiting the site the first time, more specifically around the user agreement presented to them the first time they logged into the site. The story was something like:

“As a user, I want to be to able to accept the user agreement so that I can access my content”

The details of this story included a specific workflow to follow if the user didn’t agree, including errors to show them, and a need to refrain from showing the user agreement again after agreeing to it the first time.

Conversation around this story went on for a while, mainly focusing around the second part, how to handle remembering what the user did the last time they visited the site. There were technical details about where this information needed to be stored that hadn’t been agreed to yet, and team spun a bit around this issue.

The suggestion was made to split the story into two. The first story would be the same as the first, “As a user, I want to be able to accept the user agreement so that I can access my content”, and it included all the acceptance criteria other than the remembering part. The second story would be “As a previously logged in user, I will not be presented with the user agreement, since I had already agreed to it”, which picked up the remembering part.

By splitting the story in this way, they were able to work out the important part for the customer, which was the user agreement workflow, and defer the technical issues over where to store the agreement status until they could discuss the issue more.

Moral of the story

When discussing a story, if there is contention about how part of it is done, it is sometimes possible to split the story so that the understood part is separated from the not understood part, allowing progress to be made. In this case, we knew how to write the workflow, but not how to prevent the user from seeing the agreement each time. We split the story at that particular edge, which allowed the team to build something useful, and to defer what they didn’t know yet until they knew more about it later.

— bab