.. and why I’m willing to live with it.

Brian Harry has started a series of posts on how he writes code. By the way, he is responsible to manufacture a small software package called Microsoft TFS, so I usually listen to what he has to say,

The first posts refer to both his iterative process of writing and TDD. One if the points he raises regarding TDD, is that although it is a good way to focus, and define APIs for example, the nature of new code being less robust than the final code, and that makes it less effective.

He has a point: TDD helps you focus, write the correct code you think at the time. But because TDD starts at the unit level, you run the risk that the code will change when you know better, and then you’ll need to modify the tests as well.

We developers haven’t figured a way (yet) to compensate for tests getting broken for lack of understanding, not seeing the big picture and other changes in software. Some of the tests are destined to be changed. This is one of the objections we hear sometimes – the extra extra work. Not only do we need to add work by writing tests, we also add work rewriting them.

But such is the nature of the beast. You can tweak the process as Brian does, but only to some effect. I’m willing to pay that price of added work in order to gain readability and quality. Not to mention the fact that I need to think before I write.

The accumulated benefits outweigh the re-work.