I’ve written before about my thoughts on outside in development and we came across another example last week where we made our life difficult by not initially following this approach.

The rough design of what we were working on looked like this:

My pair and I were working on the code to do the calculations and we deliberately chose not to drive the functionality from the UI because the other pair were reworking all our validation code and we didn’t want to step on each others toes.

We therefore started driving the code directly from the individual calculations and decided to create an object to represent each of the types of calculation. It worked quite well for all but one of the calculation classes, 'Calculation3, which became increasingly complicated as we added more test cases.

At this stage we rotated pairs and still unable to see a way to simplify 'Calculation3' we decided to try and drive it from the object which would actually make use of it.

As Darren Hobbs pointed out in another discussion:

In this case it became clear that the missing object which could drive out the Calculation objects was a 'Calculator':

We started writing tests for the calculator and initially it didn’t seem to make that much difference - the design of nearly all the individual 'Calculation' objects remained the same.

However, once we got to the tests which would drive out the functionality currently in 'Calculation3' it became clear that we had actually got 3 objects inside 1 and that what we really needed in this case was an orchestrating class which could delegate down to small objects to do the calculations.

The most interesting thing about this situation for me is that I often do drive code from the outside in and I’ve even previously written about the benefits of doing so but in this context I got it wrong and it was a slightly painful lesson!