LeadingAgile is Now LiminalArc. Read the Full Announcement

Move beyond isolated AI experiments to build scalable, domain-driven systems with AI-ready architectures.

Enhance valuation and accelerate ROI through due diligence, tech migrations, and strategic restructuring.

Control cloud costs, streamline data, and focus investments on high-value, scalable solutions.

Streamline operations and improve decision-making by aligning your ERP systems with how your business actually works.

Reduce risk and increase resilience by closing the security gaps hiding in your architecture and workflows.

Optimize operations, restructure teams, and modernize technology to maximize the value of digital investments.

Deliver mission-critical software in production-ready increments that create measurable value early.

Reduce risk and complexity with every cycle, turning legacy systems into platforms that can evolve.

The belief that shaped us — and how it evolved into LiminalArc, the natural next step in our journey.

Our team of over 100 experts spans the nation, from consultants and technical architects to product specialists.

We are looking to hire mature, pragmatic consultants who are deeply passionate about meaningful change.

Always TDD? But Certainly Not for Startups, Right?

Jeff Hoover Lead Engineer
Reading: Always TDD? But Certainly Not for Startups, Right?
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. Bforgoing TDD in hopes of getting something in front of customers quicklycompanies risk being shackled with an inflexible design that will be more difficult to change later.  

The relationship between TDD and startups is tricky, thoughIf 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. 

Next The Business Strategy Silicon Valley Giants Use to Disrupt Industries

Leave a comment

Your email address will not be published. Required fields are marked *

×