Should you TDD on a Lean Startup?

“Tests don’t matter and are a waste of time and money”. Yeah, right…

Sometimes when we catch up in a conversation involving Lean Startup the subject of Tests and TDD get in the way. As always there are haters that say you shouldn’t use TDD (or even write tests) in your tech startup because that’s a waste of time and money. Of course, that sounds reasonable for the novice lean-er guy; if you think Lean Startup is about “don’t build anything your customers don’t want” the idea of tests doesn’t directly drive any value to your customers. Think about it: will your customers have a better experience just because you have really good code quality? No. If you’re building the wrong product, but still it’s well tested and has amazing coverage, will that prevent you to fail? Of course NOT! But testing and TDD on a lean startup is important for other reason.

It’s true that the lean philosophy indicates that the waste must be minimized. Everything that doesn’t drive value to customers should not be built. That’s a fact, and belongs to the Lean methodology (the roots of Lean Startup). But, how do you know what drives value to your customer? Iterating and learning, the cornerstone of lean startup. Lean Startup focuses on “Validated Learning” and uses it as a unit of progress. In order to do that you have to go through the build-measure-learn loop:

As Eric Ries says: “Startups that succeed are those that manage to iterate enough times before running out of resources” Time is crucial. The more iterations you can make, the higher are the chances to find a sustainable business. We can argue then that one objective we can have is to minimize the time we spent on the build-measure-learn loop. If we make that time as small as we can, we’ll be able to cycle around it more times and the chances to run out of resources are lower.

This is where tests (and TDD) comes into scene. Having a solid tests foundation allows you to move fast when experimenting. You can have a hunch (based on a Leading metric, of course ;-) ) that says “we should remove this thing” or “we should separate that form in two parts” that you want to test. But what happens if any time you want to run your experiments the whole website blows up? Your speed through the loop gets downgraded. You’re slowed down, and you’re even jeopardizing the experiment with weird bugs that change the experiment randomly.

That’s why tests and TDD are crucial for a lean startup. Tests allows you to iterate fast and with a high level of self-confort and security through the build-measure-learn loop.

I mention Tests and TDD all the time because you’re not strictly obligated to TDD in order to have a solid tests base in your project. But for me (and this an arguable opinion) it’s the best way to do it. I find it really stressful to go back and look at some piece of code and write the tests in order to make them pass based on the code instead of the opposite (and better for me) way.

Finally, a note about code quality and good practices.

There are some coding practices developed on the past 20 years that are built just from coders experience. That means those were not created by a bunch of academic dudes which just wanted to fill a 10-page paper. They were created because they were needed, born from other coders needs. Most of them are included in XP (Extreme Programming): Pair programming, Integration, coding standards, and of course, test-first or TDD. All those practices have been around for a long time and have been proved effective. Don’t hesitate to make a move and incorporate one of those. We’ve spent a fairly big amount of time in our deployment process (thanks @dustinmcquay‎) and I regret nothing. We’re able to ship code in seconds, with a really stable process. I’ve also tried (not enough I’m afraid) pair programming and it’s absolutely awesome. Again, we hackers are part of a wise, collaborative and smart community. Aim for quality.

What do you think?