TDD is dead!
Wait…what? The patron saint of Ruby on Rails wrote that post proclaiming the death of Test Driven Development and then outing himself as a non-practitioner of TDD. Lets step back for a minute real quick though.
What is TDD, anyway?
First, what is test driven development. TDD is style of software development where before writing functionality, you start by writing a little test. Only after writing a test, do you begin writing the code to satisfy that test. The goal is to develop a set of confirmatory tests that tell you that your code is doing what you think it is while you continue making changes. Another goal is to support the business by making software better and changes to software a little less risky.
I think what David is saying in his post is that TDD has become dogmatic. He suggests that it is used to the extent that software has become overly complicated at the expense of developing these tests and now doing this is the standard. Also, he suggests that real software testing has been sacrificed on this altar of confirmatory tests. Maybe he is right, but the hardline position is concerning. If DHH was only saying something along the lines of “TDD isn’t enough…”, I think we as a dev community get that without provocative blogging.
Dogma meet dogma
About 10 years ago when I got started in software testing I heard rumors of this new fangled style of development. The folks that knew about it were craftspeople by virtue of seeking out that kind knowledge. Those people actively thought about what they were doing. Realistically, these people were working in the fringes of software development culture, most didn’t and don’t bother with new techniques. Eventually, TDD worked its way through time and space and now TDD is almost a household name.
The commoditization of Agile, with a capital ‘a’, has nudged all of this along. In the current Agile world, development styles like TDD are mandatory, hiring an agile coach is a good thing,, scrum is part of your daily ritual like breakfast, and continuous delivery is the goal you shoot for.
I don’t recall any of that stuff in the agile manifesto, but there it is…
This is the sort of philosophy that is great for people selling training, and certifications, and packaged services, but it isn’t doing any favors for the software industry or the people paying for that software.
So, how does all of this effect the software biz?
My hunch is not all that much, and maybe a little on the net negative side. When people with a large audience come out and say something like this, people take it to heart rather than spending time investigating and experimenting to find their own truth. This means that whatever value and tribal knowledge was there, is disposed of without really thinking about situations where is really can solve business problems. Topics like this always make waves for a little bit and then maybe they latch on, or maybe they don’t.
My suggestion? Do what Lean suggests (smell that sweet irony!), find the value in your product and focus on that. Development fads come and go. Paying clients stick around for value, not cool test frameworks.