Opinion: TDD and startups - you are all wrong (or right)

Introduction

There has been a lot of buzz lately about a post of Uncle Bob Martin, who claims that skipping Test-driven design is the worst mistake you can make when in a startup. This generated a lot of yay-and-nays on the twitter sphere, with mostly black and white opinions. I think they might all be right, but miss one important distinction: you always need to formalize what you are working on…

“So what” - Miles Davis

In my opinion, you need something to drive your behavior of your app, or as you put it in the context of startups, you need something to drive your search for a market fit. So while TDD might provide you “better” code in the end, it is not the code that matters, it is the behavior of the code that is all important. TDD for a startup should help you to reason about that behavior, i.e. what exactly are you trying to achieve.

Defining in an explicit way what (and even why) you are going to do something before you do it, allows you to:

  • focus on your task
  • define scope
  • reason about it in a strategic way

If you are able to reason about what you are about to do in another way, please feel free. I can think of at least 5 ways to define what you are doing:


So, whatever comes naturally to you might be the best fit. The most important thing is making something explicit (aka “ze cunning plan”), as I have found out multiple times in the past: without a proper plan to support your vision, you are doomed to wander around in eternity, as you never have a proper definition of done and/or scope, or even priorities…

As a developer, the best fit for me is usually some kind of a bastardized combo of all the techniques mentioned above, even combined with some impact mapping or other DDD techniques…

On a sidenote: currently halfway into Vaughn’s IDDD book, and this proves to be very helpfull as well, it’s like Eric Evan’s blue book, but written in a more accessible and pleasant way…

Conclusion

So in the end, what it all comes down to, is that you need a formal/explicit spec about what you are working on, whether that is a design doc, some unit tests or something else, does not really mather; just find out whatever fits your methods best.

comments powered by Disqus