Pair Programming in the Clink


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.

User Comments

1 comment
John Daughety's picture
John Daughety

Actually, I like this slight divergence from the normal boudaries for the weekly column. I recently watched a documentary on solitary confinement and am glad to hear your experience of a different kind of prison - human interaction is really important and giving them the opportunity to work with folks on the outside is a nice benefit. I would also argue that coding is a very appropriate skill to be teaching prisoners, as I consider it one of the core "trades" of the new millenium. It certainly opens up a released prisoner's options from the usual manual labor, which pays less and less if you can find that kind of work. Also, Dan was very smart to include you because coming up with user stories is not something that comes naturally to a developer but really sets him/her apart from the other developers if he/she can do it well. One thing I have learned in my career, drifting from waterfall-dominated environments to way-out-on-the-edge agile shops, is that daring to understand the parts of agile development that are not strictly defined as development work builds better relationships in agile teams and results in better developers. This is not just true of developers, either; testers who sequeser themselves in only test-related work are limiting their career options as well. There has never been a better time to reach out, even if it feels a bit clumsy at first.

August 25, 2011 - 6:46pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.