Mark Needham

I had an interesting conversation with my colleague David Santoro last week where I described the way that I often pick out the riskiest parts of a story or task and do those first and David pointed out that this approach didn’t seem to fit in with the idea of outside in development.

The idea with outside in development as I understand it is that we would look to drive any new functionality from the UI i.e. the outside and work our way inwards through the various layers and probably eventually end up with persistence i.e. the inside.

In the particular example that were basing our discussion on I described a story that I was working on with my pair where we needed to apply some constraints to certain items in our data set and then display them differently on the UI as a result of that.

We went through the existing domain model to see if there was anything in there that we could make use of, and having realised that there wasn’t anything we mapped out the tasks we would need to do to implement this functionality.

The most difficult/tricky task was to handle the data migration as we realised that we would need to add an extra column to one of the tables. We also needed to do the associated Hibernate mapping and the code from the UI and controller level downwards to make use of this.

We did the data migration and associated work first and one we were happy that was working we went and coded from the UI downwards until we reached the persistence layer.

In this situation it seemed like it worked out reasonably well and I couldn’t see that we would have ended up with a different solution if we had started off driving through the UI.

In fact we did end up spending most of our time doing the data migration so to me it seemed somewhat justified doing that first since we did run into a couple of problems.

Outside in development in general seems a good thing to me so I’m curious as to whether I’m justifying a sub optimal approach to myself or whether there are some situations where we can vary the approach a bit?

I’ve spent most of my time working on agile software development teams over the last few years so for the most part each pair is only working on one story, keeping the work in progress low and allowing them to focus on that piece of work until it’s completed.

My pair and I ended up in a therefore somewhat unusual situation last week where we were attempting to work on three things at the same time and weren’t doing a particularly great job on any of them.

It wasn’t immediately obvious to me that we were doing this since the two extra tasks that we were working on were related to deployment issues on different environments.

However we eventually started making mistakes and in rushing to rectify those made even more mistakes since we were still trying to concentrate on three different things.

It became much more obvious at this point that we needed to just pick one of the items and focus on that until we were done which also served as a reminder that it’s good to use the story board as an indicator of what everyone is working on.

In this case two of the tasks we were working on weren’t on the story board otherwise it would have been more obvious to the rest of the team that we shouldn’t have been working on two of them.

I’ve never really noticed the problems of context switching before so it was interesting to get such a stark example to remind me of its dangers.