Continuous improvement and TDD

It’s an old message, in a 2009 talk. But it’s good to recite the arguments every now and then, especially with such a great talk. And of course there’s the bonus of the other material which is actually the focus of the talk; the history of Smalltalk and how it “died”, according to Martin, due to messy code, parochialism/arrogance, and inability to deal with real world or enterprise requirements.

But back to the reason I’m linking this video, continuous improvement. Code tends to be messy, and needs constant correction, continuous improvement, to not collapse into an unmanageable, unmaintainable, unintelligible ball of yarn. So, code tends to be messy. What does this mean, and why is this the case?

Well, software is complex relative to our ability to write it. So it’s unlikely to get code right the first time. Secondly, writing code occurs when not all the information is available. This compounds the first point, and makes it even less likely to get things right initially.

But not only that, the fact that information is not available, or that in fact, changes as code is written, has the consequence that the code will evolve to hit a moving target. Changes to code again leads to messy code. The reason is different than that above. It’s a matter of coherence, not of correctness.

So in this simple model, we have two main driving forces that point to messy code. Intrinsic difficulty of getting things right and incoherence due to changing requirements. In theory, these are not unsurmountable. “All” it requires is constant improvement and correction. However, constant improvement requires a lot of discipline and mental effort to undertake. So constant improvement is not carried out and code gets messy.

The main point of test driven development is to lower the mental effort required for continuous improvement, by addressing its biggest obstacle, fear of breaking things. So the logic goes, reduce the fear of breaking things -> reduce the mental effort for continous improvement -> reduce the level of mess.

As I said, it’s an old message, nothing new here, but it’s worth remembering every now and then.

One thought on “Continuous improvement and TDD

Leave a Reply

Your email address will not be published. Required fields are marked *