For startups, does Test-driven Development make sense?
We often get this question asked by enterpreneurs who are coming from “tech” background especially from a larger organization where Test Driven Development – or TDD as it is known – is practiced.
Let us first understand what TDD is. According to wikipedia, “Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.Kent Beck, who is credited with having developed or ‘rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.”
So far so good. The definition of TDD is promising and offers a good level of comfort because the code is well known from the test’s perspective. The question is, does it make sense to the startups?
Well, it depends. In most cases, as a startup, you don’t need to focus on having confidence in your code. Your focus should be on identifying product-market fit and build around.
When you are validating your product idea, it might be an overkill to use any such methodologies including TDD. Sure, TDD has its merrits but the important question here is, what a startup is going to lose if it does not use the TDD?
Nothing, right? Maybe there will be technical debt. Maybe there will be inferior quality code. Maybe the code is messy and not as clean as it should be…
But the thing is, as a startup, your focus should not be not on clean coding or writing reusable code. Instead, your undivided focus should be on validating the product-market fit – your solution
We are not saying that clean coding, reusable code or methodologies such as TDD are not useful. Certainly they are but depending upon the startup’s stage, it is an overkill.
Our learning on this concept comes from our research on executing the projects the agile way. In Agile, you focus more in individuals and interactions, not processes and tools.
Sure, processes and tools have the value but as a startup, if you cannot build interactions with your people who matter to you (e.g. initial employees, potential customers) as soon as possible, you’re out of business.
No process or tool can help you stay in business if you don’t do that.
Now this is easier said than done and it would sound counter-intuitive to people whose background is in process centric organizations but those organizations are trying to maximize the efficiencies, they are not fighting with the survival question.
To give an anology, consider your startup as a battlefield. In battlefield, there are no rules. You live or you die. And you do everything possible to live. If you have tools that help you live and you can make its effective use, by all means use them otherwise do not worry about them.
If you focus too much on tools, then you will have expensive failures. It is good to have failures as long as you learn from them but expensive failures come with stress, heartburning or even divorces.
So while TDD – or any other process for that matter – might make sense to some startups, startups can choose to ignore it deliberately and validate their product-market fit first and reach to a predictable future.
When the products and services of a startups become predictable, it no longer remains a startup, but becomes a company and tools such as TDD can help companies go a long way.