Thought Driven Development a Methodology of Abile Development

Warning: This is a rant against TDD extremism! Sensitive TDD people better step out of this dark sleazy communist place right now!

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.

Architecture blues

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).

Why “Abile“? Because Agile starts to feel pretty rigid these days. I guess the people enforcing waterfall process rigidity in the past didn’t magically become flexible once they switched to Agile.

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.

17 thoughts on “Thought Driven Development a Methodology of Abile Development”

  1. As soon as you start equating Bridge building with Software development, seriously, you’ve lost me.

    Rebuilding a bridge and loosing thousands of trucks is very expensive, writing a unit test is very very cheap.

    BTW you say “I feel directly accused of releasing untested code to the unsuspecting public. ” and then go on to explain exactly why you should do. For shame.

  2. TDD helps me to think through to the right solution and has the added benefit of leaving a trail of tests to verify, confirm, and enforce my thought process.

    Sounds like you’ve been talking with/reading, etc with people who aren’t doing TDD correctly and it’s backfiring on them (which can indeed happen).

    TDD is the culmination of a number of other good principles, practices, and processes and if you’re not doing those, or aren’t doing them correctly, then TDD will actually trip you up and hold you back, no doubt.

    This post seems like a rant against people doing TDD, Agile, etc half-assed and without the rigid discipline and dedication that GOOD Agile/XP/TDD require to be successful.

    Such is the case with any discipline, no?

  3. This was a good read (albeit a bit off base). You have some very valid points hidden in the rant. It was a pleasure digging through the garbage to get to them.

  4. you suck ! you suck ! you suck ! … (patrick repeated this 1000 times… how smart of him)

    @Patrick I got your point. You don’t have to be an idiot. (Daniel)

  5. I’m mostly reading between the lines here, but I’m guessing you are interacting with someone that’s trying to force you into TDD. Or possibly attacking you for not doing TDD.

    There are a number of people in the community that do this. I mostly chalk it up to the learning process. It’s like a kid that just learned the word “no”, and is getting some results using it. It sometimes gets clouded by a person who has adopted TDD and feels he/she is getting great value out of the practice. That value produces a bit of passion which bubbles over and can be perceived by others as aggression or condemnation for those who don’t share a similar view.

    We know, however, just like the little kid, that this is just a part of the learning process. Trying to take the passion away would be to deny the TDD zealot the reality of a learning curve. I’d suggest keeping this in mind.

    The other thing I would ask you to do is look at the value of the practice. While it’s possible the some people may adopt TDD on gut feel alone, most skeptical people (you and I) need to see the value produced by the practice before we really even give it a chance.

    From one skeptic to another, I’d ask you to look at the value produced by the practice and then make up your own mind. That alone, was ultimately, what drove me into TDD, but again, this is something you need to make up your own mind on.

    I would also suggest you look for the value based on your own experience and wit. Don’t expect to find a definitive, single reference explaining the value behind the practice.

  6. hey,

    agile zealots are gonna post some hate comments on your blog. i hope they feel really good for getting the last word in with their comments. it might give them more a smile when they’re smelling their farts and writing unit tests. hope they don’t make you feel really sad or anything.

  7. I can’t knowledgeably comment on TDD, but I am impressed to by your insightful and correct application of concepts, conceptual hierarchy, and essentials, in software development.

    I also like your identification of the nature of developers and testers.

    Saved, sent, and bookmarked. I’m posting to recommend you investigate ITOE (if you haven’t already) (Amazon: Introduction to Objectivist Epistemology)

  8. You said: “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. ”

    I would argue that when you have to solve a problem you need to first focus on the problem and the expected outcome. Before TDD, there were countless times I implemented a solution for the wrong problem.

  9. 1. Never compare bridge-building with software development. Comparing some goods production with “service”-businesses is even more correct.

    2. You compared the developers and testers mindsets – it’s incorrect.
    TDDs prime is not in testing in a classical form. TDD is a way to develop, not a way to test software. QA people may even never know about low-level development practices used in development dept behind the wall.

    3. “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.”

    Wrong example! You don’t test if it’s “x”, you test if x is equal to 10 (for instance), not 9.9 or something else when you expect 10 and equals 9.9 when you expect 9.9.

    4. “If you focus on tests first… how do you know what you are testing?”
    If you write the code first (or least)… why are you sure this code is necessary?

    5. Without TDD as a really modern approach (it’s not just a toy) – how to make sure if every line of code you write is necessary and how to know if it doesn’t break the other code until it comes back from QA?

    P.S. Sure, TDD has its drawbacks from management aspect as well as from engineering but it is worth deeper understanding before writing something like this article which contains lots of juggle with facts.

  10. Some responses in order:

    @Anonymous Coward
    It is a rant so I am allowed to exaggerate. Related to the shame part I am sorry but I feel none. I test my code enough where it matters. And I decide where it matters by thinking. I’ve seen TDD guys testing every little setter and getter and then not testing the networking code because it is too difficult. Or using mocking object that don’t react like the real thing…

    @Chad Myers
    As I said in the post I have nothing against the people who use TDD and are successful doing that. I have a problem with it being pushed down my throat. I hate dogmas of any kind. I have a problem with half-assed things in general but I also have a problem with Agile moving into a very rigid methodology only because it has to be sold to the big enterprise.

  11. @Evan
    Thanks for the balanced response. Maybe indeed my opinion would change if I would encounter at least one case where TDD is applied right and reaps all the benefits with little problems. My problem is not with the idea of testing one’s code but with the focus on testing in development. Testing assumes you have something to test. Declaring the methodology TDD leads beginners into focusing on that instead of the design. And I have seen ugly results coming out of this mis-focus.

    @godlike? maybe…
    I am not sad, I am amused. I know the experienced people who found success with TDD would understand my rant and maybe ignore it or give a smart answer. Only kids or people unsure about their skill level resort to personal attacks.

  12. @Adam
    Thanks for the book title. I will check it out.

    @Perry
    I am not sure what is the difference beyond nitpicking. To find a solution indeed you have to understand the problem, I agree.

    @Vasilio Ruzanni
    1. This is a rant, the bridge comparison is a metaphor
    2. That is your opinion. I think developers should develop. I also think testers should be more involved in the development process so they can test what needs to be tested.
    3. I kind of get your point but in 20 years I never had a bug in a getter or setter.
    4. I use my brain to think about the problem.
    5. Again see #4. And let me tell you code written by the TDD principles still has bugs.
    6 (the PS). Where is the juggle with facts? Can you point me to some studies on the benefits of TDD in long term: cost of development, cost of maintenance, customer satisfaction? Until we have those we juggle opinions.

  13. “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.”

    This example demonstrates one of the reasons why TDD is a good idea. If you write tests before you change code, you can test as you develop!

    Leaving them for some maintenance programmer to write after development has finished doesn’t help at all until the next work is done on the system.

  14. TDD demonstrates that you go and try to break something before you even build. How stupid.

    I bought a plot and i am planning to build a house. My requirement is house walls should be strong enough to suruvive truck accident. So what if they dont survive? Lets see. So TDD says “Go and get a truck and see if it crushes you or not?” Expected result is : Truck should not crush me. Actual Output: Truck crushed TDD developer.

    Happy Programming!!!!!!!!!!!!a

  15. I’ve been training people on TDD and the *first* thing I said is you need to start from the functional spec and then (maybe) create a technical spec that is used to drive the tests. Understand the problem first – and then the tests are just part of writing the code as a whole, no biggie.

    Writing small tests for small bits of code make you think small, with short well focussed methods that *do* stuff. Long linear honkin’ bits of procedural code are very hard to test properly. TDD has the accidental but very useful effect that you write stuff that isn’t tightly coupled because it’s impossible to do efficient TDD with tight coupling, assuming you get how to do it well. That takes practice. I think you should give it another try from the beginning with something simple and notice how the structure of your code is better (IMHO anyway).

    When I’m doing demos or quick tracer bullet things then I don’t bother, but then there are no consequences.

    I agree that agilistas can be far too rigid – don’t substitute process for thought. Anyone who ever suffered under RUP (or any big MC company’s “method”) knows how painful this is.

    Testers test functionality. Programmers test assumptions. Not the same.

Comments are closed.