First up, thanks to Adam Esterline for coordinating last Saturday’s code retreat. Then thanks to Rally Software for hosting the event, for sponsoring lunch, and for supplying a half dozen developers. It’s great to see a company with multiple software craftsmen interested in spending a Saturday working on their craft. And thanks to LeanDog for sponsoring breakfast and consistently looking to sponsor craftsmanship in the software community.
As an added bonus, due to the small crowd, it was decided that we’d head up to the real office and use actual pairing stations for the day. Pairing does not require a nice setup to work. The biggest benefits are simply in the collaborative nature of writing code. That said, pairing can be tiring, since it is such a focused, concentrated effort, so it is nice to be able help facilitate that focus by having a comfortable setup where each of you can easily see what’s going on in the code, make changes, and not be constantly turning the monitor so you can get a better view. This setup was different than ones I’ve used before. Two very large monitors, two keyboards, and two mice composing two mirrored setups attached to a common Mac tower. The monitors were set on the corners of the tables (rather than side-by-side),facilitating face to face discussion (when not focused on the screen). It was a nice switch from a 15” laptop.
We followed the Corey Haines prescribed method of code retreating (see How It Works) for the most part and after a basic introduction to Conway’s Game of Life, we began iteration 1.
At the start, all the pairs were thinking the same way, work top down. Start with the Grid. (I swear this wasn’t my influence) This crew was already quite proficient at TDD and at things like keeping methods small. In turn, this iteration was about getting our brains into the game. In my pair, we only ran into to some trouble once it got down to the point to code up the rules for the Cell. Until that point, all steps were precise and small. The trouble was now avoiding a big step, but the iteration ended, so we reverted everything and took a break. (In retrospect, I think we were thinking too big for that next step. We’ll see if the next time I remember some of my later thoughts on avoiding that.)
Something that happens to me every time I work with Game of Life (similarly LCD Display kata) is I end up drawing out examples. Here’s a rendition of the index card we had:
One of these times I really want to go ahead and give a shot to iterating on some simple visualizations. Maybe a Grid.visualize() using System.out.
Iteration 2. We switched pairs and again had a common curiosity of how would this feel differently if we were to start from the inside with Cell. The cell was put together pretty fast. I was quite happy with our 1 line implementation (and it would have still been 1 line if we had fixed the bug in it). We still had a bunch of time, so we went to working on the Grid. Even though we didn’t end up completing the Grid still, it was insightful that we weren’t going to have any of the “big step” issues we ran into at the end of iteration 1. Given the Cell had its rule set to evolve, it was easy write simple tests for evolving the Grid.
On to iteration 3 and "TDD like you mean it”. I’m still fascinated by how to make this work, but I need a lot more practice. I think Adam and I were the only two who had tried it before, so the rest of the group was new to the concept. Short version: it’s fun; it fries your brain a bit.
After lunch, we moved into the experimenting stage. For iteration 4, the experiment was avoid using if statements (assertions in tests not included). I don’t have great notes from my pair’s results, but the other pair ended up in an interesting place. From what I understood, they created a decision table of some sort where each cell could map its evolution from its current state. From a distance, it looked complex and not exactly expressive. They also got caught up in the data, which caused some slips in their test driving. An interesting concept, that I’ve seen something like in production code, so cool to see how making it expressive is a real challenge.
Iteration 5’s experiment was nothing but 1 line methods (return this; // didn’t count). My pair and I got rolling along pretty quickly. Having done some experimenting with fluent interfaces before, this helped us especially in the tests to keep to 1 line; not test 1 thing; not assert 1 thing; but 1 line. Fun :) As we got deeper into Grid though, it got more challenging. We decided to go ahead and get to green with many line methods (read: nested for loops) and then refactor. (Again in retrospect, I think we needed a smaller step here.) Anyway, we put our refactoring hats on and started to pick it apart. It was definitely good practice in finding ways to extract methods and the code did get more and more expressive.
Finally iteration 6 (getting tired), we had a bit of discussion around being Acceptance Test Driven. Since we were in Java, we were discussing JBehave and looking at how that would have influence the design of our Grid’s interface. I do see this as a benefit to ATDD (and BDD), but I’m most interested in getting people to work this way in order to emphasize the importance and dramatic effect of having a discussion about a requirement in terms of specific (executable) examples written from the user’s perspective by a collective of analyst, developer, and tester. But I digress...
It was a great day. For me, very nice to be close to home. And as is always the case with code retreats, it was great pairing with other craftsmen, off the treadmill of the normal work day. It was a very insightful day for me. I need to find another one to attend...
But wait... as it turns out at Agile 2010 in Orlando this August, I’ll be facilitating a code retreat session (Wednesday, 11 August 2010, 09:00 - 10:30). We’ll have 2 shorter than normal iterations, but for those interested we’ll continue iterating afterward in the open space. Hope to see you there.
0 comments:
Post a Comment