Update: Robert Martin is scheduled to appear on the Feb 10 episode of the SO Podcast.  Should be interesting to see where things go.  Also, Jay Fields has weighed in on the topic.

Update #2: Listened to the new SO podcast and am working on a short followup post.  I just met another local boy and kindred spirit in Justin Etheredge who has also had a few things to say about this whole debacle.

I wanted to add my two cents to this philosophical, in my view very important, but not very pragmatic debate. For the uninitiated, the argument begins with the Stackoverflow Podcast Episode #38 which is a discussion between Joel Spolsky and Jeff Atwood.  They discussed, among many other topics, some of “UncleBob” Martin’s recent material found in his book Clean Code, (actually, Spolsky cited Martin’s appearance on Hanselminutes as the spark to his comments), which Martin responded to with a number of tweets and a blog post.

Jared Richardson introduced me to the idea of technical debt, (term was coined, like so many other terms, by Ward Cunningham) which I think is a pragmatic way to cut through the philosophical differences in this argument.  But in the interest of carrying on the debate, and because it’s the weekend, I’ve decided to (perhaps) add some fuel to the fire.  Please don’t read this at work.

The gist of the argument is about how much emphasis you should focus on robustness/code hygiene/maintainability in your code, even if it is unclear there is much business value in doing so.  Essentially, if we consider impacts to budgets, deadlines, etc., and even in terms of its impact to your code (see Antipattern: “Yet Another Useless Layer”) — is it worth it?  It’s very much a discussion of what software quality is and why is it important, which raises questions like:

• Are robustness and business value mutually exclusive?
• Does quality require rigor and conceptual cleanliness?
• Is code hygiene a purely academic pursuit, or is there intrinsic value in it?

These are interesting questions.  Atwood and Spolsky take what they feel is a more pragmatic position; Atwood explaining quality in terms of a Frank Zappa quote [paraphrasing] “Nobody gives a crap if we’re great musicians,” meaning that what matters is ultimately what is delivered to the customer. He explains further that “Quality is just another axis” — another set of competing concerns for your development time and interest.  Spolsky’s comments constitute a self-professed rant that there is a thread of zealotry in the OO community around TDD.  It reminded me a lot of what Cedric Beust has argued in reference to what Jim Coplien has debated with Martin himself.  While Spolksy could be playing devil’s advocate, or could have been looking to start a “blog fight” (already popping up in comment threads) I think he could have gone about it in a more pragmatic way.  While Beust does paint Martin as a zealot as well, at least his main point didn’t portray unit testing as just short of completely useless; rather, he is one of the creators of the popular TestNG framework:

“Tests first” or “tests last” is unimportant as long as there are tests.

I might be wrong, but I even remember reading a section of Clean Code in Borders last week and essentially reading Beust’s point in Martin’s book.  It stuck out in my mind after watching his debate with Coplian.  But I digress.

Before going further, I wanted to point out how much this debate reminds me of From pirate dwarves to ninja elves…, which I believe is a great way to classify personality types — especially those of people writing code.  We know for sure that UncleBob falls into the Ninja-Elf quadrant.  He thinks practicing TDD is a professional responsibilty and lays out his own definition for TDD in Clean Code.  I think this is the very definition of a Ninja-Elf.  My personal leanings are toward that quadrant as well. When you are innundated with Dijsktra, the ulitmate Ninja-Elf, in school, the following quote really sticks with you:

I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself “Dijkstra would not have liked this”, well, that would be enough immortality for me.

But there are people whose opinions I respect with Dwarf-Pirate leanings, too.  Obviously Atwood and Spolsky lean in this direction (though they may not fall directly into that quadrant).  I’ve heard some others that I respect espouse the same opinion as Spolsky; Gavin King, for example, I’ve heard him say, “The types of bugs that I introduce usually aren’t caught by a unit test.” He wasn’t as over the top in his argument, he simply explained that he prefers integration tests.  And I don’t think you’d hear any of the people mentioned in this post say that they never write any tests.  For a great argument from the ultimate Pirate-Dwarf see Cal Henderson’s normalized data is for sissies (slide #27); it is pretty entertaining and compelling when scalability is of utmost concern.

I think Atwood’s argument ultimately came down to championing the idea of continuous production; that being able to respond to change or bugs found and having a quick no-brainer deployment process is the Zen-like state you’d like to get to.  But the idea of getting there is that it comes out of some notion of continuous integration, which is predicated on the idea of testing.  Henderson himself makes this very argument (I believe in this talk, but perhaps in another). You need to trust your team enough to get changes and fixes out to address problems quickly, and be smart about what you spend time on. Testing is great and if you can find people that can test their code well and be productive, that’s awesome. But Henderson’s point is those people are extremely hard to find and retain.

All this goes back to the old question, is producing code an artistic or engineering practice?  (Interesting that Atwood supported his comment with a Frank Zappa quote about art.)  Obviously you need a talented and cohesive team to be able to make it work either way. I think the answer is it has to be a little bit of both.  You’ll need some measure of creativity, some degree of engineering aptitude, also strong analytical skills, and to succeed in a business environment, some acumen in decision making and managing (at the very least your own time).

The fact is, though, that we’ve come leaps and bounds in terms of being able to efficiently produce these tests, and balance their production and maintenance out with constraints, business expectations, budgets and deadlines.  And it can fuel your creative side, too.

As for professional responsibilities, I definitely wouldn’t recommend trying to write code without at least some tests if you expect anyone else to have to maintain your code. If you’ve got a close knit team and an overwhelmingly urgent need to deliver untested code (and are of the Pirate-Dwarf persuasion) then go for it.  But that being said, I’d say I agree with Martin and Jared Richardson that argue it’s a professional responsibility to not take on the technical debt of untested code. Of course, if tests mean you can get maintainability (and other -ilities) along the way then I think that you’re well on your way to a quality product.

One final way to look at this: would you say it’s better for your team to take the view that code is innocent until proven guilty, or guilty until proven innocent?  In the interest of skepticism, considering the teams that most developers “in the trenches” have to work on, and how far we’ve come in making testing easier and more efficient, I’d need a very strong team to make the assumption that all they code they write is innocent.  We all make mistakes.  I believe this is also brought up in Clean Code.

Ultimately the message Atwood and Spolsky send in their Stackoverflow podcast is that unit testing and efforts to support it are not a silver bullet.  Personal slights aside (“I don’t think these people write very much code.”) they have a point — and Martin agrees in his blog post.  But I think it took them a long time to make that point which is certainly no great revelation.  In the end, I did not feel they explained a whole lot about what the right approach to quality is, but communicated their distaste for an attempt (especially if accepted dogmatically) that aims to do so.  I can relate to this, and agree you must treat what you read, hear and are taught with a healthy dose of skepticism.  Martin’s ideas may seem dogmatic on the surface but I don’t think it’s fair to paint him in that light.  If you really read what he writes, I think he realizes that he is a voice many people are listening to, and works hard to say what he thinks is the right.  Martin defends a style of development that favors more rigor and discipline than many others feel is necessary, but in an industry that can be categorized by its lack of discipline, I can’t do much but respect him for that.