Our pairing approach was to enforce pairs between the hours of 10am and 4pm, with an hour for lunch in between.  I'm an early starter, so at about 7:30am I started working through the list of things I noted down from yesterday.  I refactored method and variable names, changed a couple of data structures and method implementations.  I ran the tests once after performing all my changes, one test failed and was fixed, then I ran the tests again. 

My partner rocked up at about 8am, we caught up quickly on the changes I'd made over a game of foosball, then did our own thing until our 9:30am stand up.  Between 8am and 9:30am I didn't really have any other coding tasks, so I picked up an old attempt at using RhinoMocks to solve our TDD woes.  After an hour I'd managed to completely gut all the work that had been performed the day before to make it easily testable.  I parked this branch for later.

Status Report

We reported at our stand up that we'd be finished the story in 2 days, and that we'd be blocked if another story wasn't completed by the end of the day.

We now had a test for each testable condition in the story, with real implementations throughout every layer down to the service layer, which was returning hardcoded error messages.  We still had to replace the hardcoded messages with real implementations, and implement the store and retrieve functionality that was the bulk of the story.

Easy Does It

By lunch, we'd managed to store our document and pass our final test for the first part of the story (or so we thought).  As we implemented the document store function, we realised that the story contained some invalid assumptions, and was performing unnecessary validation.  A quick discussion with our business analyst and solution architect resulted in the de-scoping of two validations and the reworking of another. 

We removed the two fully implemented validation rules and re-wrote the third.  The lesson?  Implement the easy or "success" case first, then deal with what can go wrong.  If we'd done that, we would have saved somewhere between 1-2 hours including all the time that was wasted on frequent test runs on day one by identifying the story issues and removing the rules before we'd implemented them.

Testing Times

After another game of foosball at lunch, I picked up the test branch from my solo session in the morning and tried to work it into a usable alternative to exercising the tests within IIS.  I managed to get it to the point where I was able to easily test boundary conditions for the validation rules, but only after I moved them into a class that didn't inherit from our base service class which didn't allow the injection of dependencies (i.e. mock objects) without a massive amount of spring framework trickery.

I ran through my progress with my partner after lunch and then proceeded to delete the branch - it wasn't workable given our application's current design.

Moving On

Getting back into pairing, I implemented the retrieval function, then switched to navigator while we tidied up our implementation.  We noticed while cleaning up that a business rule had been missed, it still contained the hardcoded test implementation.  We started down one implementation path briefly, discussed a better solution and then corrected the implementation.another function was implemented and tested. 

About 5-6 rebuild / run test cycles were performed over the space of an hour - that's 30 minutes elapsed time, and a full man-hour down. 

9 Hours In - End of Day Two

The morning session was a good learning experience, and our next function was implemented at a much faster pace than the first.

However, I found myself getting up from the desk and moving around for the duration of the afternoon session.  I helped out other team members, continued discussions from the previous day regarding Martin Fowler's Anaemic Domain article with my peers and attended a meeting in between stints as driver and navigator. 

I felt like I was at the computer for no more than two of the 3 hours.

Even though we both had equal stints as driver and navigator, we still missed the hardcoded validation rule - but had enough time to complete the first two functions in the story on schedule.  That leaves tomorrow to implement the final function.

I'm starting to think that pairing would work great in an environment where TDD practices could also be effectively used, but that it's not providing the enough of a quality improvement to justify the additional time spent on the task. 

In our case, the inability to rapidly test / implement / execute results in wasted down time, where the navigator is disengaged and the driver has to actively resist the temptation do other things while waiting for tests to run.