I listened to them a lot when I was traveling last year, this was when Jeff and the gang were creating Stack Overflow. I'm done traveling and hadn't really made the time in my life to catch up on podcasts until now. And it's kind of nice doing it this way because you get "full seasons" of podcasts and don't have to wait eagerly for the next. That's how I watch TV for the most part, watching one episode a week is for the dogs. So although I'm still a few episodes behind, I managed to get through two I feel need a "rebuttal" of sorts. The two I speak of are episode 38 and episode 41
Episode 38
In this episode it's Joel and Jeff talk about Test Driven Development and how they don't get why it's so useful because really if you are a software company you should just hire awesome programmers who don't need to write unit tests. This position is pretty much born out of ignorance, and I'm not being a jerk here, I love Jeff and Joel, I just recognize their ignorance for what it is.
For instance, Joel says at one point:
It doesn't seem like you could actually get any code written if you're spending all your time writing 8,000,000 unit tests, and every single dinky little class that you need to split a URL into four parts becomes an engineering project worthy of making a bridge, where you spend six months defining 1000 little interfaces. They've just gone off the deep end, and I don't think these people write very much code if they're coming up with these principles, to be honest, it doesn't even make sense.
Joel essentially explains that TDD is akin to the Object Oriented Architect who is operating up in his ivory tower, dictating what should be a really good idea in theory, but essentially is impractical in the real world and should be left to the academics to debate.
Episode 41
Episode 38 spawned a rebuttal from "Uncle Bob" -- one of the pioneers of the Agile methodology -- he's also a big proponent of TDD. The episode includes Uncle Bob himself, however he's unable to convince Joel and Jeff that TDD is for the real world and the episode essentially re-iterates Joel and Jeff's stance that if you just hire "awesome programmers", these time-wasting unit tests aren't worth it.
I must admit I was left disappointed, I really thought Uncle Bob would give them the what-for, show them that TDD is alive and well outside their island code base. Uncle Bob, in my opinion doesn't do a super job trying to convince them of why TDD make sense. I got the feeling that he didn't want to bring into question Joel and Jeff's coding practices. For instance, Joel brings up several times how "there is lots of code in the UI layer that you simply can't unit test". That should signal alarm bells for the astute programmer who has grown accustom to the Model View Controller paradigm (or Separation of Concerns in general). I really think the problem is that .NET people (I was one briefly) are trapped in the Vendor Vacuum which is Microsoft. If Microsoft doesn't have a unit testing framework that is bundled in with .NET, then it's probably something not worth looking into is the mantra. I base this opinion primarily on what I hear Jeff talk about during the podcasts, specifically how early on in development of Stack Overflow they weren't sure if they were going to implement the site using this new "MVC" thing. For a person like me that's been doing MVC web development since the 1.x versions of Struts (circa 2000), I cringed. It all goes back to Joel's comment about all the little pieces of logic in the UI, that just shouldn't be the case. I won't go on about it ad nauseum, I'll just hug Wicket and let others experience the pains of <% logic here %> programming (or "bee sting" tag programming as Jeff might say) in the UI until they too have their "ahah" moment (or until Microsoft has it for them).
On "A Hah!" moments...
I've done what they've done though; forming opinion on things that I have no experience with. I did it with the Mac, Sushi and of course technical things like distributed source control. I've taken a position now that if I haven't tried it, I probably don't have an opinion on it that is worth a hill of beans. I got the feeling that after all was said and done Joel and Jeff still weren't convinced that TDD was for people who "really coded"...
There are just some things like DSCM and TDD that you just have to try for yourself to get that "ah hah" moment. Without that moment, you really have to be a special person to grasp firstly the concept and secondly why it's important and useful. When I first discovered git (thanks to fellow basementcoders Marc and Alex) I didn't really know why this was any better than svn. Then I started using it, and discovered how much more agile I could be, for instance I could be merrily working away on some future feature of a software app and instantly be able to code an emergency fix for a released branch. I can do all that without switching directories and without loosing any work I was doing on my feature.
Make Unit tests, not User testers
The funny thing is, in later episodes Jeff laments about a certain Stack Overflow badge for which faulty logic caused the badge to be awarded to users when it shouldn't have been. Instead of making his users be his unit testers, he could have caught this up front with a set of unit tests for the badging system.
It's actually, when you think of it, pretty surprising that Stack Overflow works as well as it does. This is primarily due to the community which supports and makes Stack Overflow a success, they find the bugs early enough and the bugs get fixed fast enough that on a whole the site works. But there will come a day where the site becomes a complex set of features which start to become coupled to one another. Jeff or one of his partners will change some innocuous piece of code, and because of the lack of unit tests to support regression testing, 5 other bugs will be introduced. That's not a "maybe it will come to that", it's pretty much a fact and users will only put up with so many bugs before they'll get frustrated.
Cover your ass - the blame game goes away...
Cover your ass
This is precisely the problem that lead me to have my "a hah" moment with TDD: it's inherit ability to "cover your ass". What you do is you build up a set of programmatic tests which exercise the functionality of your unit (most likely a service, or set of services). You then set your build system to execute these unit tests anytime your program is built. If the unit tests fail, the build fails. If the build fails, it means the last change set you made "broke the build". That is the key, you must enforce a protocol upon your developers that states "before you check *anything* into SCM, you build it and run the unit tests. If the build fails for any reason, unit test failures included, you fix it before you check in.
This needs to be a commandment of your development process that is enforced with extreme prejudice. I learned that from Jeff Genender, the hard way a few times. If you checked in code that broke the build, he came down on you like a sack of hammers.
The accountability comes into play if you also incorporate Continuous Integration tools. For instance any time we checked in source code at Leap Frog, Jason Whaley had our Continuous Integration server automatically build the code and run our unit tests. If a unit tests or compilation failed a big nasty email went around to the team, and to the directors stating "${name_of_jerk} broke the build".
It also really helped that we had top notch QA personal, Chas Schley and Brad Epranian would not tolerate source code which wasn't properly unit tested. They themselves were writing a series of automated testing against various parts of the system and it pissed them off to no end when all of a sudden their tests weren't working anymore because of your change.
Knowledge Transfer
The fact of the matter is, disregarding everything else, TDD makes you better at understanding your program. If some developer on your team doesn't know anything about how the "badging system" works, I guarantee you if you pointed him to a set of unit tests which exercise the ins and outs of badging complete with the happy paths and corner cases, he'll have a much better chance at understanding it and being able to contribute fixes and new functionality than if you just set him loose on the code base itself.
Conclusion
I really hope I've made my point and I hope this helps somebody, somewhere (if not Joel and Jeff), to understand why TDD isn't just an academic pursuit or a masochistic technique that only "obsessive compulsive" programmers partake in (as Joel might say). It adds real value, and real quality while broadening your team's understanding of your product.
To Joel and Jeff....
I don't know if Joel and Jeff are sick of this topic, maybe it's been beaten into the ground too much already, but I'd love if either they would join us on our podcast or us on theirs to rehash some of the issues. So Joel/Jeff if you are up for it, let me know, I'd love to talk further.