One of the things that irks me when discussing certain technical topics is a tendency towards boosterism that can hinder, or even halt, deeper evaluation and discussion. Some topics, tools, or practices arrive with a divine imprimatur of authority that is hard to resist. Since I believe in being personally responsible for the software development I undertake, I sometimes find myself exploring murky territory that seems like it should be better mapped. The latest of these pre-hallowed principles is Test-driven Development.
What comes across as a casual assumption of superiority gets my hackles up. I'll show what I mean using a recent post by Derik Whittaker titled Sound of One Man Testing. I want to be careful up front, though, because my purpose isn't to pick on Derik. Indeed, I really liked a previous post of his describing his love of being a software developer. I suspect that I'd like him if I knew him personally. I'm just using his post so that I have concrete illustrative examples for what I'm reacting to. His post is in good (and numerous) company.
TDD or A Poke in the Eye with a Sharp Stick
I mentioned this before, but it keeps happening. The comparison to TDD seems to always be a complete lack of testing. This is always a flawed comparison. It doesn't matter if you're addressing heathens or saints, it simply carries no useful information. It promotes sloppy thinking and lazy arguments because you set such a low hurdle to beat. It's worse than unconvincing because it irritates people who disagree with you and thus erects barriers to communication.
It is a textbook case of the Straw Man logical fallacy. Defeating a straw man isn't really much of an achievement and pretending that it is doesn't make it so. Skipping straight to 50 when counting out pushups is only impressive to someone who didn't notice. It doesn't actually do you any good and will certainly never result in those ripped abs your SO goes on about.
Derik says "Following TDD is more about your mind set and attitude [than] it is about the process in my opinion." David Tchepak recently made a similar point (admittedly tangential to his post) in his generous response to my earlier comments, "I feel TDD has the potential to change the way you think about coding."
I get their sentiment and I'm not trying to dismiss these statements out of hand. Attitude, mind set, and perspective matter, and things that keep you focused or have other purely mental benefits have a place in software development.
It's just that these benefits are highly personal and hard to make relevant. If you include them, it is helpful if you can make sure that they are an important part of your point and that you develop them in a way that stands a good chance of connecting with others. Failing to connect them to your larger point makes them stand out, weakening the whole.
Many posts about TDD are aimed at those who are already convinced. Derik's post is one such—he is clearly addressing those who already believe in TDD who want arguments to help them bring TDD into non-TDD environments.
Which would be fine in a discussion group or forum, but is more problematic in a blog post. Blogs are, by nature, public (I've seen private blogs but I really don't see their point). Blog posts are likely to be read by people who don't share your basic assumptions. It is wise to bear this in mind when discussing potentially controversial topics.
Addressing an in-crowd comes across very poorly for those who don't consider themselves part of your community. It's like those jerks in High School who talk about others in public as if they weren't there—which is essentially what you are doing.
Take this section of Derik's post, for example:
Benefits the project will gain
- Better code coverage
Even if you only can cover 5% of the code in your tests, that is 5% less code to worry about
- Increased code quality
Do I really need to explain this?
- Increased code reliability
Do I really need to explain this?
- As foundation to grow on
Because you have [taken the initiative] to create the test plumbing (i.e. configuration, db setup, logging setup, etc) you have reduced the barrier of entry for other developers. I have found that this barrier of entry is a common reason people don't want to start testing. I know it is lame, but I have heard it.
Someone not already convinced of the superiority of TDD can take what looks like a casual disregard for their perspective poorly. My inner spite-demon pops up like a jack-in-the-box and says things like "Yes Derik, you do really need to explain this." or "Do you really mean to say that covered code == code you don't have to worry about?" or "Taking the initiative to provide infrastructure only you use sounds a lot like wasting time and resources to me."
While I got over myself (and reminded myself again that I liked his previous post), the reminder that I'm not in Derik's clique is off-putting. If you don't want to re-hash arguments that you feel have been established elsewhere (a perfectly reasonable impulse), give a link (or at least a reference). Bear in mind that there are reasonable people out there who don't share your convictions and if they show up you would probably like it if they would hear you out.
Remembering that Reasonable People Disagree
There is an unfortunate human tendency to believe that all smart people agree with you. The corollary is that anyone who disagrees with you is stupid. The thing is that even if you are right, communicating from that perspective doesn't work out very well. Reminding yourself from time to time that people disagree with you and some of them might be worth reaching out to is a good habit to cultivate. I know that I'd personally take it as a kindness.