TITLE: The Rare Pleasure of Pairing AUTHOR: Eugene Wallingford DATE: June 01, 2010 9:39 PM DESC: ----- BODY: When my student team began the second iteration of our project this morning, one member had no partner. So I jumped in to fill the void for half an hour or so. When the missing student arrived, he joined us and we worked as a trio. What a treat! Most of the time, I code alone, and far too often the only code I work closely with is code I have written. Working with another programmer was a lot of fun. We talked as we studied and tried our ideas about how the code worked out on one another. Studying someone's code added a second dimension to the fun, because neither of us brought much experience with this part of the system to our pairing session. That meant real study, and real learning. Our programming session reminded me just how valuable tests can be. We bounced back and forth between the class we needed to extend and its tests. We would study the code, come up with an idea of how it worked, and then inspected the tests to confirm or disconfirm our idea. At one point, we were studying a particularly confusing method. We finally figured out what it was doing and went to the tests to check our understanding. But there was no test to help us... and there should have been. So we wrote a test that embodied what we thought should happen, ran it, and -- voilé -- it passed. That felt good. The story my partner and I picked out turned out to be effectively solved by the existing code. Rather than taking the easy way out, mark the story as done, and grab another story card, we decided to clean up the code a bit. We were a bit disturbed at having to study that confusing method so long and generally at having to work so hard to understand the class as a whole. So we refactored the class to express the code's intent more clearly. The biggest product of our clean-up was a helper class to structure the parts of a journal entry and name them. This meant taking a horizontal slice of data that was originally sliced vertically. This clarified several of the internal interfaces and even simplified one hairy loop with an if statement that selected on value type into two simpler loops. Ahh. Is the new code better than the previous version? We think so, but we won't know until the next developers to touch it, whether others our ourselves, bump into it again. I will say that it is at least more explicit. The intention of the code shows up in the names of local variables and formal parameters; it shows up in blocks that send messages to objects of the same kind. It shows up in tests that make finer-grained assertions about the behavior of the system. That feels like an improvement to me and, hopefully, my partners. We'll know more soon enough. I would love to have more chances like the one I had today. -----