I used to believe in Agile Programming. I tried XP and Scrum. But at some moment the Agile movement moved onto milking the cow. Expensive books – lots of them – appeared on amazon.com (I still like them only when you buy them from my Amazon bookstore – it helps cent by cent to pay for this site’s hosting). Expensive consultants sell their opinion on how I should be Agile.
And on top of all TDD (Thought Deficit Disorder?… no, Test Driven Development/Design…) acuses everybody of not being professional. I feel directly accused of releasing untested code to the unsuspecting public. For example I don’t write a test instance.getX() to make sure, but absolutely sure, it gives me the value of x and not the value of y. This kind of attitude will only create a push-back reaction.
Wrong focus by the name
Why do I pick on TDD? Because it makes no sense. The development and design shall be driven by thought not by test. Yes some people are able to “think” better about their problems while using TDD. Kudos to them! But not all people are alike.
There are lots of problems with TDD but one of them is paramount: it focuses on the wrong thing. I hear what you mutter – no, it doesn’t… and I tell you again – it focuses on the fricking wrong thing. When you have to solve a problem you have to focus on finding a solution, then on making sure the solution is the right one. If you focus on tests first… how do you know what you are testing? You will say requirements tell you that. And I’ll tell you “are you kidding me?”… wasn’t Agile supposed to assume requirements can change at any moment?
Let’s assume I am an architect building a bridge. I don’t bother designing it, I am practicing TDD. I think about testing the bridge first. I get 1,000 heavy trucks all filled up with lead and make them cross the bridge. Well I have no bridge yet and all the trucks go straight to the bottom of the river. But this is not bad, not bad at all, it is the right thing to do. This proved that I have no bridge yet and as I was suspecting from the beginning the test failed. This is a big success.
Now I start building the bridge to make sure my 1,000 trucks will never be able to break it. Since I am an Agile programmer in all aspects, I have to do this in a sprint with a pair programmer (dead weight?) on my back. We sprint together with our feet in the same bag and deliver a shaky wood bridge. The test fails again and now I have 2,000 trucks on the bottom of my river. This tends to be a problem in itself since I started to build a bridge and I got a dam made out of trucks. But what the hell, at least I designed the tests. In the next sprint I will double the amount of wood and put more screws and hope it will hold. Or maybe the requirements will change and I will be asked to build a dam.
All software creations have a central idea, a core concept that defines them. That core concept drives their life-cycle. A text editor will always be a text editor. You cannot make it a database. You can make it a text editor with some sort of database on the side but nobody will use it mainly for the database functionality.
This simple fact, the existence of the core driving concept, limits dramatically the scenarios where the Agile claims that requirements can change at any time. Yes, surface requirements can change often and unexpectedly but the core requirements won’t.
The architecture of a product is all about this core concept. It requires investigation, understanding and a solution. I don’t think TDD as it is presented today take this into account. Some experienced people that practice TDD know this and the focus on the right thing, but most don’t because to get to that level of experience requires… well… experience.
I agree with Jim Coplien: “TDD done strictly from the YAGNI principle leads to an architectural meltdown around iteration three.” and I am not alone. I would only emphasize that YAGNI doesn’t put the focus on the core concepts.
What is TDD anyways
Does TDD work? Yes, sometimes for some people! But what do they mean? The name of their religion (TDD) is or should be self explanatory. The Wikipedia article on TDD gives this feeling of clarity. But now I hear actually TDD is something else, something that focuses on design and architecture and refactoring and so on. TDD not mainly about getting tests to pass? In that case change the damn name because, I am telling you, lots of people are confused and most of the people who claim to do TDD do it in their own little way. And they are accused of “not getting it”!
I start to suspect that people who like and apply TDD successfully just discovered their own unique way to some degree of success in their specific field. They found their own path to Nirvana but they fail to see that it is not the only possible path. Lots of people who don’t do TDD discovered ways to success and blissfulness.
Code mass/churn increase
There are other problems with TDD. One of them is a proliferation of tests. Tests are code and the more code you have the more bugs you have, statistically. Tests are tied tightly to the code they are testing. In the early phases while prototyping a developer is likely to change his mind many times. This will lead to a lot of test rewrite when practicing TDD. You may end up with thousands of lines of code written and placed in the garbage for every few tens of lines of production code.
Lots of tests also add weight to the maintenance process. Of course there is the advantage of being able to run regression tests. But when you have to refactor or change the functionality of the production code because of new requirements this is not a bonus anymore. The code changes, the tests have to change too, and this is now done probably not by the original developers but by some unlucky maintenance programmer.
Because of the cumbersomeness of managing all the extra code some people think about generating tests!!! This way they can only prove that the code does what it does. But it also proves that anything taken to the extreme is not only worthless but also dangerous.
Developer mind set vs tester mind set
One of the least covered subjects in all the debates on software development methodologies is the human factor. People think in different ways because they have different backgrounds, educations, experiences and genetics. Some people are better at writing code other at doing testing. Some people naturally like long term tasks other prefer short term tasks. These individual variations determine if a person will like and as a result be successful with TDD, or any other xDD, or not.
Developers are focused on creating things and solving problems. They have to think about complex interactions between concepts. They have to think about the evolution of these concepts. They do creative work.
Testers are focused on breaking things. Their job is to try to break things in various ways, to imagine scenarios the developer didn’t consider. They have to find and uncover holes in the developer’s solutions. They do detective work.
Developers and testers both do essential but complementary jobs. TDD tries to make developers think in a way that is not natural for them. I always thought XP would be a better practice if pair programming would’ve asked for a developer to be paired with a tester all the time!
The not so sexy real solution
TDD is an attempt (as countless others) to find a solution for an undefined problem. Software development is present everywhere nowadays. The countless variations in domain, problem, platform, requirements… all add a huge number of variables to the development process. Whoever thinks TDD is a one size fits all kind of solution didn’t get his head out of the sand yet.
The real solution is hard to swallow because as the problem itself is not fully defined. Your development has to be thought driven. Think! Reflect about your problem. Find out what other people are doing and thinking. Learn about methodologies like TDD. Practice them if you find them useful in your case. But don’t pass the responsibility of thinking to the process. It will not do it for you.
There you have it – my solution: “Thought Driven Development” a methodology of Abile Programming (TM).
Hmmm, maybe I should write a book about this, sell it on Amazon and at the same time certify some consultants in Abile… food for thought.