#2782

Supporting practices… TDD and Shared Space

An casual conversation with George, the PM on CodePlex, got me thinking about XP’s notion of supporting practices.

How does TDD support the notion of shared space? Superficially it doesn’t but in fact for me it’s really helpful, whether I’m pair programming or working on my own. Inevitably in a team room you have to deal more interuptions than you would if you were working in an office with the door shut. Here’s two scenarios that illustrate how TDD helps with that.

#1 – Old Skool

Working on a problem… I have large chunks of the application “assembled” in my head. As I change code I have to remember all the dependencies and what else I might have effected with as I make modifications. I may or may not have some unit tests and the acceptance tests I have might takea while to run. Old Skool in other words.

Doing this well requires me to get into a flow state. When things get tricky it can feel a bit like playing chess in your head. When I’m interupted I have to drop the problem and then pick it back up. The cost of doing that is fifteen minutes or more.

#2 – TDD

TDD. I’m changing one small piece of code and while this may have lots of dependencies – I have tests around those too. TDD forces me to tackle the work on the problem in a linear fashion and break it into small pieces. The tests ensure I know the state of progress at every step. When I’m interupted the effect isn’t as significant because TDD has forced me to serialize the workflow and tackle one small problem at a time.

The other things I like to have to hand when doing this are a list of stories – which makes sure I don’t forget any functionality during context switches – and a whiteboard or paper diagram of what the application design might looks like. These allow me to pick up on the general direction of work after longer breaks.