I recently came across a post by Ayende where he talks about the need for tests to justify themselves and describes his approach to testing which doesn’t involved TDDing all the code he writes.

While this approach clearly works well for Ayende I really like the following comment by Alex Simkin:

This reminds me of a conversation I was having with a few colleagues a while ago where we were discussing whether we should look to test drive absolutely everything that we write or whether we should make that decision on a case by case basis.

Personally, I don’t yet have the experience to be able to tell when it’s appropriate not to drive code (excluding spiking) and pretty much every time that I’ve decided something was 'too easy' to test drive I’ve managed to make a mistake and not realised it until much later than would have been the case with a test driven approach.

I’m finding that this applies to more than just testing though and it seems that where an approach is known to reduce a lot of potential pain then it might be useful to favour that approach unless we find an intriguing reason not to.

Thinking along those lines I think it makes sense to follow some 'rules of thumb' and not break them unless we absolutely have to.

Some rules of thumb which I’ve come across are:

Given a situation where I want to reuse some code and I know that I could choose between doing it with composition or inheritance I wouldn’t consider this a 50-50 choice but instead would look to use composition unless it became really difficult to do this and inheritance was clearly the answer in which case I would use that.

Obviously these 'rules of thumb' might be a bit restrictive for people at the higher levels of skill of the Dreyfus model and I imagine that even with people with less experience they could be quite dangerous if applied too literally.

I wonder whether being dogmatic about a few rules of thumb would be more or less dangerous than making decisions not to follow a useful practice because you mistakenly believe you have the ability to tell whether or not it applies in a given situation?

Corey Haines wrote a really good post where he talks about the misuse of the word 'pragmatic' which seems to address this area although he comes to a slightly different conclusion:

Typically when people try to justify a shortcut this is exactly the way they will justify it. The irony is that quite often much suffering is gained from that decision so it wasn’t really that pragmatic after all.

I realise that there aren’t really any rules for software development that we can follow all the time and expect to gain success with but it does seem that some approaches have already been proven to be more effective than others so it might be useful to make use of them.