Mark Needham

Nikhil and I were discussing some of the ideas around Test Driven Development earlier in the week and at one stage I pointed out that I quite liked Bryan Liles’ idea of ‘make it pass or change the message‘.

Bryan suggests that when we have a failing test our next step should be to make that test pass or at least write some code which results in us getting a different error message and hopefully one step closer to making the test pass.

As I described this to Nikhil he pointed out that this is probably what most people are doing anyway and now the technique just has a name.

I think this is probably a fair assessment but then again I find it very useful when people give a name to common techniques/patterns as it makes them much easier to talk about without having to fill in a whole load of context.

For example Joshua Kerievsky has come up with some names to describe incremental refactoring techniques such as parallel change and narrowed change.

Parallel change describes a technique where we want to change a method signature but don’t want to break all the clients of that method by directly changing it.

Instead we create the new method alongside the current one and gradually move the clients to call the new one instead. When they’ve all moved we can delete the original method.

Narrowed change describes a technique where we try to reduce the number of places where we have to make the change we want to make.

It’s much easier to use the vocabulary that Kerievsky has come up with than to have to describe the techniques each time!

However I do think it is possible to go too far with naming things to the point that there are actually so many names that it’s incredibly difficult to remember them all.

xUnit Patterns seems like an example of this to me.

There are an incredible number of patterns described in that book and while they do all describe slightly different scenarios I’m not necessarily convinced that having this many different patterns makes our discussions easier.

Overall though I think having names for common patterns in software development is a good thing and it does add value even though it seems like we’ve just ‘given something a name’.