Always TDD? But Certainly Not for Startups, Right?
Startups need to be ultra-Agile and able to get fast feedback on experiments by getting work out in front of customers rapidly. There’s an element of racing against time when a company must achieve success with only a certain amount of capital to burn through. Startups need to be able to pivot quickly in response to what they learn in their experiments. Some people in startups believe that developing software with Test Driven Development (TDD) will delay their time to market, so they avoid using it and may go as far as saying TDD is incompatible with startups.
My experience with teams of developers skilled in TDD has not shown the delays that its detractors fear. Code developed with TDD is particularly well-suited to rapid change down the road as demand for updates to the product increases.
The specifics of how code written with TDD facilitates rapid change is a subject for another article.
In software development, prototypes, experiments, and proofs of concept often end up as the production code base. Few companies have time for rewrites, and this is especially true for startups. By forgoing TDD in hopes of getting something in front of customers quickly, companies risk being shackled with an inflexible design that will be more difficult to change later.
The relationship between TDD and startups is tricky, though. If I develop my startup without TDD, I’m likely to end up with a hard-to-change and hard-to-maintain project that’s prone to defects. But learning TDD takes time. It’s not a simple matter to start using TDD if you aren’t experienced in it. Developing software with TDD when you are new to it is slower than developing without TDD. There is a non-trivial learning curve. If I have a startup idea and I want to learn TDD before starting on it, I’m likely to miss my window of opportunity because of the ever-changing nature of the market. As a developer, I would not want to try to learn TDD while working for a startup, and as a startup, I would not want to jeopardize our ability to get to market quickly to allow developers to learn TDD on the job. So, while not all startups are configured to benefit from TDD, I disagree when people say that startups shouldn’t use TDD.