Pair Programming in the Clink: Page 2 of 3

The hallways seemed to go on forever. Finally, we reached our destination—the software lab. We were welcomed by the entire class—I think eight total. Lee, a very gentle guy with thick glasses (he told me he is almost blind) and a shock of black hair, was the organizer among the prisoners. He fussed over us, making sure we had places to sit in the somewhat cramped space between two rows of computer workstations.  It turned out we would not be using these computers, as none of them had Java loaded on them and they were under-powered. Our workstations were in the next room—the computers usually reserved for graphic design. Hey, if it can run Adobe Photoshop, it can run anything.

Dan and Lee walked us through our exercise for the day: Dots. Dots is a kids’ game where you draw lines between dots and try to make squares faster than your opponent. Our mission was to try to build the Dots game in teams of two, one “insider” and one “outsider.” We had forty-five-minute blocks to do our pairing, after which we would retrospect and start again.  And I really mean start again.  After each pairing, we wiped our hard drives of any code we had built and started with a new Java project. In other words, your pair was never going to finish building the Dots game in the allotted time. This was actually the point. Dan and Lee wanted to create an exercise with no pressure to finish and no reason to mess up our good programming practices to gain a little speed. And what practices were we practicing?  Well, our goal was to instill agile development practices, not just teach Java. So, we focused on pair programming, of course, as well as the SOLID principles and test-driven development (TDD).  Of all of these, TDD is the hardest to learn. Many developers have tried TDD, only to fall back to their previous “test last” processes.

My first pairing was with Lee.  Everyone had kind of planned this, because I had made it clear that I was a terrible developer, and we all knew that Lee was a great one, so he could get me started without too much embarrassment. We opened up a Java project, imported JUnit, and away we went. I was immediately hit with my first “D’oh!” realization: Prisoners don’t have Internet access, dude. When you run into a problem that you know a bunch of people must have had before, you cannot Google it.  Now, that’s a big change from how we develop today (on the outside).

I was pretty impressed with Lee’s development skills and coaching ability. He seemed to be quite confident but without a hint of arrogance. Dan had warned us that our biggest problems with the pairing would probably be getting the prisoners to correct us when we made mistakes. The COs constantly coach the prisoners to be polite to visitors and volunteers, so most prisoners will err on the side of “shut up” rather than upset someone. Honestly, I’m pretty sure that if anyone from the outside, especially a woman, made a scene and accused a prisoner of anything, that prisoner would head directly to solitary confinement (yes they have that) without any questions asked. What was interesting was that the COs did not sit with us in the computer lab.  The closest one was across the hall.  At the front gate in the morning, Dan was issued a little necklace that had a big button on it. Dan said that if he pressed that button, COs would appear from the woodwork and whatever situation had occurred would be no more.  I tried to keep my hands away from Dan’s button at all times.

My pairing with Lee was a lot of fun.  I relearned what I had forgotten about Java and experienced TDD for myself. After forty-five minutes, we retrospected in the bigger room, then came back in and switched pairs. My next pair was Ronny.  He had done some Java before but was clearly not at Lee’s level.  We struggled along and had to ask other pairs for help several times, but something happened during this pairing. We decided to write some “storytests” as well as the normal unit tests. Storytests test your application at the “feature level” instead of just one unit.  We decided to create one storytest and then wrote a unit test underneath it and started writing code to satisfy that unit test.  It was cool, but Ronny mentioned several times that he wasn’t good at identifying stories. He would often try to make the stories more technical than they needed to be. Rather than write a storytest that said “I want to finish a square,” he would tend to want to specify the storytest as “Squares have four sides, which can include a corner,” things like that.  We worked through these issues, and he seemed to improve a bit, as much as can be hoped for in forty-five minutes.  Next thing we knew, it was time for lunch.  But I realized I had found my niche—I could help my pairs learn about user stories.

The sandwiches catered by AmVets were pretty good. I had a sub sandwich with Italian cold cuts and a nice salad. During lunch, we listened to another prisoner (not in our group) explain the Green Initiative going on at MCI. Wow, they are doing a ton of things to encourage recycling and even to begin their own fish farm right on site. So cool. The outsiders were a bit disappointed we didn’t get to go to the mess hall and maybe witness a food fight, but, no, we ate our food right in the computer lab. The prisoners assured us we weren’t missing much from a culinary perspective.

One funny thing: When people get prepacked lunches, they sometimes look at a bag of chips or piece of celery and say “I don’t like this; anyone want this?”  On the outside, maybe someone else will take it off your hands; maybe nobody will.  In prison, there was never any food offered up that didn’t get snatched immediately.  Bags of chips went into pockets, cookies went into little hiding places.