TDD'in Your Life

October 28th, 2007

Oh yes, you read that right. TDD as in Test-Driven Development.

I actually stole the subject from my friend. We were talking about benefits of applying TDD in the target domain – that is, designing computer software – but the idea of applying TDD to your life isn’t just fun (if you’re odd enough) but practical as well. The real reason, of course, is not in the tool itself but the philosophy or abstract principle behing TDD which is much more general and not restricted to computers.

The principle.. no, The Principle because it deserves special emphasis, is of course having Incontrovertible Objectives whenever you want to achieve something and start for planning it. For the sake of discussion, let us assume that the task or activity in hand is of such nature that planning ahead is suggested.

What I actually mean by Incontrovertible Objectives? the idea is just as in TDD applied to software: when you write test first, you are setting concrete and unambigous1 assertions describing how the code concerned should behave. As a result, your tests work as a specification against which the outcome of your activity will be compared to, thus resulting either in success or failure.

The crucial point in here is tractability. The goal doesn’t have to be quantifiable, but it has to be specific enough or expressed in such terms, so that before starting the work you have simple means of evaluating the outcome afterwards: success or failure. An example would be organizing an event: organization is successful if a) selected people are sent an invitation 1 month before the event b) the invitation includes the event location, event time and schedule as well as contact information. It might seem like an concocted example, but it serves as an example: if there are eg. delivery errors, the organization was still successful according to the “spec”.

Naturally you can’t apply this principle everywhere. But it is very useful in many cases and actually used by many experienced professionals – not only in the IT. Our CEO is extremely good in this: she often goes like “Yes, yes, I understand your point but the important thing is: how do you prove you’ve finished? just telling it’s finished just doesn’t cut it. How do you define finished? Can you show it? Is it traceable?”. She’s really good at these things, and I know I’ve learned lots of things by just working with her, things I couldn’t learn anywhere else.

As you noticed, I just invented a new solecism, INOB. Rad.


[1] ok, not exactly, because to really specify behavior accurately and unambiguously, you’d need so many tests, that you would never release any software more complex than “hello world”, due to exponentially increasing path branching and number of test cases.

Leave a Reply