Uncharted Waters

May 7 2014   12:42PM GMT

Replacing one dogma with another

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

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.

3  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • MGEakin

    Well said Justin. I believe Kent Beck would agree with you that "TDD isn't enough.." As I understand it, that is why he created BDD; which includes ATDD and TDD. TDD in a vacuum is deadly as you don't know where to start, often don't know when to end, and the path to go from start to finish is often blurry at best. Basing everything off team-agreed-upon Acceptance Criteria test cases & scripts gives developers all that. In this framework TDD thrives. High quality code is continuously delivered by developers which meets the needs the business laid out in the User Story.

    You lost me on the second half of your post; your rant against "the commoditization of agile." The problem with any "philosophy" is that without the tools (agile-specific software, unit testing software, coaches, etc.) and processes it becomes very hard to implement. In other words, you cannot implement the principles behind the Agile Manifesto using Quality Center in a traditional waterfall shop. Something has to change. To meet that need SCRUM was created, people began to get trained to be agile coaches & ScrumMasters, developers began learning about TDD, testers began learning ruby/cucumber, etc.. I wouldn't call that the commoditization of Agile. I would call it evolution.

    50 pointsBadges:
  • Justin Rohrman

    I was trying to say that I think the gradual change of agile from a set of principles to a set to tools and methods has contributed to the problem. My observation is that some orgs say something like "OK, we do daily stand-ups, release in sprints, and have cucumber tests. So we're agile now, right?". The original intent was to see where you are currently, where you want to be, and then take a step toward that. Rinse, wash, repeat. If you think you're there, and stop working to improve, then you're no longer there :)

    Basically, what I'd like to see is a focus on delivering software faster or with higher quality if you want to deliver software faster or with higher quality rather than adding in TDD because you don't currently have TDD. 
    2,130 pointsBadges:
  • MGEakin
    LOL I was in a discussion a while ago about that very topic. 1st thing the Agile Manifesto values is "Individuals and interactions over processes and tools." Yet the 1st thing some of the signers did was create processes and tools to help with those processes. Ironic, huh? 

    To me TDD fits into the 2nd value: Working software over comprehensive documentation. The only way to prove your software works is through tests. Unit tests prove the software works at the unit level; integration tests prove the units work together and with other applications/sites; acceptance tests (GUI layer, business tests) prove it does what the business wants. If you take any of these tests out of the mix you are now missing a critical layer of proof that what you are building is doing what it is suppose to be doing. This leads to a domino effect of (justified) mistrust and usually much lower quality of code. At least, that has been my observation.
    50 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: