An old friend of mine recently posted a video blog that I found to be brilliant.

Mike (GeePaw) Hill presented Five Underplayed Premises of TDD on a web page that contains an article and a video. The video and the article appear to be identical in content; so you can read, or listen, or both. However, there is much more information in the video, because Mike’s passion is an effective seasoning to the solid content of his article.

The primary thrust of Mike’s message is that TDD helps you to:

• Deliver Value Faster.
• Exercise Good Judgement.
• Improve Internal Quality.
• Increase Efficiency.
• Improve External Quality.

Mike makes these points quickly, adeptly, and convincingly. The video is a joy to watch. The article is a joy to read. They make me hope that the GeePaw series of video blogs will continue to produce such high quality content for a very long time.

A Quibble.

But I have a quibble. And it’s kind of a big one – at least for me. And so, for the rest of this article, I shall employ the Writer’s Workshop convention of using the phrase “The Author”, instead of the author’s name.

It’s not a quibble with any of the author’s major points. Those points are perfectly solid. It’s a quibble with something the author said in an aside.

While discussing that TDD helps us deliver value faster, the author says:

“TDD is not about good citizenship. You are not immoral if you don’t TDD. You’re not not a good looker forwarder or a protector of the future. It’s not about citizenship. TDD isn’t even about raising the quality of your code. Now TDD very often does increase the quality of teams that aren’t doing it to begin with, but that’s actually neither here nor there, because TDD isn’t about that. TDD is about more value faster.

The other thing it’s not about? It’s not about art and it’s not about craftsmanship. It’s not about the excellence of our high standards. The reason we test drive is by test driving, we go faster. We put more value into the field faster than if we didn’t do TDD. And that is the money premise. We’re in this for the money.”

These two paragraphs are entirely inconsistent with the rest of the article in the following ways:

• The author asserts that TDD is not about quality; and yet his third and fifth points assert that TDD helps internal and external quality. If you accept those points then clearly TDD is about raising the quality of your code, as well as the quality of your product.

• The author asserts that TDD is not about art, or craftsmanship, or excellence of our high standards; and yet his five points stress judgement, and quality, and efficiency which are the very essence of craftsmanship, art, and high standards.

• The author asserts that TDD is not about good citizenship or morality. Herein lies the crux of my quibble; and so I must explain at some length.

By “citizenship” I presume the author means citizenship in the software community. By “morality” I presume the author means professional ethics. In the following discussion we’ll stick with the author’s words and infer their meanings appropriately.

How can programmers be good moral citizens if they are not using the best means at their disposal to: deliver value faster, use good judgement, improve internal quality, increase efficiency, and improve external quality? Is the author suggesting that a programmer who, out of negligence, goes slow, uses bad judgement, makes an internal mess, create gross inefficiencies, and delivers bad features is being a good moral citizen? I think that’s absurd.

Now, to be fair, it may be that the author’s point is that TDD is not the only way to achieve these five goals; and that therefore TDD is not the only way to be a good moral citizen of the software community. Whether that is so, or not, is irrelevant to the point. The fact that TDD helps with those five goals means that TDD is about good moral citizenship. It may not be the only path to that good moral citizenship; but it is a path.

Let’s say this a different way. Does the author believe that he would continue to be a good moral citizen of the software community if he abandoned TDD? Now, since I know the author to be such a good moral citizen, the only possible answer to this question is: Yes! Of course. Because the only way the author would abandon TDD is if he found some better means to achieve those five goals.

And so we can deduce that the five goals are the issue; and not TDD. Striving to achieve those five goals is what makes you a good moral citizen of the software community. TDD is merely one of the paths that assist in that striving.

That’s all well and good. However, since TDD is a path towards the goals, it is not fair to say that TDD is not about the goals. TDD is, in fact, about being a good moral citizen of the software community. TDD is about professional ethics.

Lastly, let me say that I eagerly await a better path to those goals. So far, I haven’t found one.