7 Reasons Why TDD Failed to become Mainstream

Contents

What is TDD?

The Debate

So Why TDD Failed?

1. TDD is Expensive

2. TDD Will Retard Your Project Launch

3. You Will Change Your Projects and Old Tests Become Waste

4. Testing the Means is a lot more Work Than Testing the Outcomes

5. Extensive Testing is Boring

6. Many TDD Preachers Do Not Use it Most of the Time But Do Not Admit it

7. Many Reputed Developers Do Not Use TDD at all

Conclusions

TDD is Not Dead Though

Other Software Development Manias for you to Rethink

Your Opinion

What is TDD?

The software development community is large. Some developers are much more experienced than others. Therefore, I think I should start telling a bit about the basics to help those that are not aware or are not sure what TDD is.

TDD are the initials of Test Driven Development. This is a process for developing software that consists in creating some code that tests if the actual project code works as intended.

This means that first you create test scripts and then you create the actual code of your project. Then you run the tests to see if at least one of them fails. In that case, you should fix your code until all tests run without failures.

Kent Beck is the developer that developed of TDD or at least rediscovered the process in 2003 as a means to promote software quality.

The Debate

In theory TDD sounds wonderful. Every developer wants to write software of best quality possible. Tests are a way to verify that the software you write satisfies the project requirements. This should not be a bad thing.

TDD is more than writing tests. TDD is about writing tests first before you write every single component of your project. This leads to a series of inconveniences that discouraged many developers to embrace TDD.

David Heinemeier Hansson, the creator of the Ruby On Rails framework published an article admitting that he does not use TDD, despite in the past he was a great defender of TDD, as the right way to do software development.

After he published that article, he participated in a public debate with Kent Back and Martin Fowler, one of the promoters of the Agile Software Development. This debate happened over several hangouts that ended recently. Here is a playlist of all the hangout videos.

Play Video

So Why TDD Failed?

The argumentation against TDD is extensive. Different opponents highlight different points. Here I am just giving my opinion based on what I think that is more relevant.

Other people may have additional points of view. Others  do not really agree with some of the my points. The idea is not be consensual but rather to give you a perspective to think about.

1. TDD is Expensive

My main objection to TDD is that it is expensive. If you need to write tests for everything upfront, obviously your project will take more time or more developers to build it.

Every software project may fail especially if it takes too much money. So, spending money ahead writing tests first, your project may even be aborted before it provides any value to those that are paying for it.

2. TDD Will Retard Your Project Launch

Obviously, writing tests ahead means that your project will take much longer to launch. Some defenders claim that the time you spend writing tests will pay up in the future if you break something.

The fact is that you only break something if you change it or change its dependencies in a significant way. So if you fear that a change may break your project, write tests then right before you make those significant changes. You do not have to write tests right from the start.

On the other hand, if you avoid writing tests for everything from the start, you gain time, your project launch sooner, so its business can be validated faster.

3. You Will Change Your Projects and Old Tests Become Waste

Very often projects change their goals because the companies behind the projects realized that they need to change to make their businesses more viable.

When the project goals change, at least part of the code becomes useless because it will no longer be used after the business goal change.

If you have written extensive tests for the code that will be dropped, the tests also become useless. By then you realize that the time waste was much higher than if you just have written code that did what it was meant to do without the tests.

4. Testing the Means is a lot more Work Than Testing the Outcomes

Very often you need to change parts of the implementation without changing the outcome of your application. By outcome I mean for instance what needs to happen or you need to present to the user.

The outcome is the the main thing to be preserved. If the outcome is broken, the means that were used to reach that outcome are possibly broken too. To arrive to that conclusion you do not have to test every little software component that implement the means.

However, the components that implement the means often represent a greater part of your software project, therefore require much more tests and you need to spend much more time on that.

5. Extensive Testing is Boring

Tests are not functionality. Tests are just verification. For many developers, spending too much time writing tests makes them feel much less productive because they need to spend much more time to see the outcome of their software.

This is why many developers do not like writing tests at all. They would rather have someone else writing them. Making a developer writing tests against his will is like torture. Programming starts becoming a pain rather than a pleasure.

Over time many developers start hating writing tests, even the tests meant to verify crucial things that must not fail, like the application outcome.

This is probably the reason that many developers that are initially TDD enthusiasts, give up on TDD forever.

6. Many TDD Preachers Do Not Use it Most of the Time But Do Not Admit it

Many developers become so enthusiastic about TDD that they preach it like a religion. If they find somebody that does practice TDD, they give them a sermon. For preachers, not practicing TDD is a sin and you will go to hell when you die if you do not convert to the TDD religion.

This would not be a problem if some TDD practitioners would not regret and give up on it. The problem is that when they give up they fear to admit it in public because they can be bashed by the preachers and they will be blamed for inconsistency with their past beliefs.

That sort of happened with David Heinemeier Hansson. Once he realized that TDD did not feel right, he avoided to comment about it, eventually to not be judged by other preachers. After 10 years he finally decided to put it all out. He does not do TDD at all.

He also feels bad for every other developer that fear to admit that they do not do TDD as well despite they were enthusiasts in the past. Some of them still practice TDD in part of their projects, especially Open Source projects because everybody can see what they did. But for private projects they hardly do it.

7. Many Reputed Developers Do Not Use TDD at all

You do not need to be very smart to figure that TDD is not something for you to do in all projects. It is even amazing that David Heinemeier Hansson took 10 years to declare that TDD is not right for him.

It is even more amazing because well known reputed developers have expressed against TDD in the past. That is the case of StackExchange founders Joel Spolski and Jeff Atwood. In 2009 they declared in StackOverflow podcast that they do not use TDD at all.

They are not the only ones to think that. The matter is that they do not have fear to speak what they think. But when they stated they do not favor TDD, they were fought by Uncle Bob in a following StackOverflow podcast episode. So other reputed developers that do not preach TDD were afraid to admit it publicly.

Conclusions

TDD is Not Dead Though

I think TDD is not really dead as David Heinemeier Hansson states. He is just angry for not putting all out sooner.

TDD still makes sense in some cases, like for instance implementing standard protocols or specifications that will not change over time.

Nevertheless David Heinemeier Hansson declaration was useful because it helped setting many developers free to admit they do not use TDD. David is a great influencer in the software development community, so many people pay attention to what he says. Too bad it took him this long to put it all out.

Other Software Development Manias for you to Rethink

For me TDD is just one mania that many developers have been obsessed with for a long time. But that is not the only one. Here are some other manias that some developers are still obsessed with because they think of them as dogmas of religions.

I will not comment much about each of these manias because it is not the focus of this article. I just list them here for you to reflect about them.

Everything Has to be an Object

Forcing Yourself to Use as Many Design Patterns As Possible

Argue Over Code Formatting Styles

Programming has to be Beautiful

Hire More Developers to Do Pair Programming

Your Opinion

One important thought that you should take away from this article is that your point of view matters above everybody else's.

Many people followed the preachers of TDD to later realize that it is not right for them. Still some were afraid to admit it and never contested openly.

You should not take others' opinions as laws that you must follow. Do not just follow blindly the opinions preachers. That includes me.

Do not follow what I say without thinking first about what is good or bad for you. If you agree with me fine, if you disagree is also fine. What matters is that you reflect about others opinions but take your own conclusions.

If you just follow others' opinions and your software projects go in the wrong direction, it will be your fault. It will not help telling your boss or your customers that you followed others opinions. That would only make you look dumb.

So, if you agree or disagree with me and would like to add your point of view, just comment to this article here.