I understand your concerns about adding to the processing load in production but the likes of new relic only add a small additional load onto the response time. Given the richness of the data you get back it is worth it.

I see your point. It looks like your company is similar to us, just wondering your experience when you quote for a job? We find that a TDD quote can look higher than a competitor’s non TDD quote. If the person is boot strapping the initial development you can look pricey. How do you get round this?

Also, if you have minor pivots then TDD is fine, what about major pivots, you can end up binning a chunk of functionality plus all the tests.

It is our experience working with customers developing new products that the speed which you are seeking is made possible by TDD.
The break even point i.e. the point at which your financial investment into TDD practices for your new software is returned by your cost saving is about 6-8 weeks.

One of the fundamental concepts in a Lean Startup is XP (If you listen to Eric Rease et al). The practices of XP are underpinned by TDD.

Our conclusions and experience with helping customers develop their product ideas is the total opposite of the conclusions contained in this article.

What we have experienced is that the cycle time between having an idea and testing it in practice i.e. the ability to continuously deliver your software and hence to run lots of little experiments as described in lean start up methodologies makes the use to TDD more critical than for other companies.
The less certain you are of the product features required and the more flexibility you need into the future the more you need TDD because the likelihood of you needing to change your existing software (in the normal course of developing your feature set) goes up dramatically. The possibility to do the infamous Pivot is created only by having a good code base without massive technical debt.

If you have a very good idea of what your feature set required is and you are unlikely to need to totally change your business with a Pivot then you can get away with manual testing. If you need short cycle times and you need to ensure that your code can be changed in directions not originally envisaged then you need TDD.

It’s not about coverage or any of that, it’s just about creating a codebase which can confidently be changed as the need arises – and in the volatile land of start-ups, nothing is more consistent than change.

It’s short sighted and I feel almost irresponsible for professional developers today not to be comfortable exercising TDD. The thing is, once people get used to it and are committed to it, the time factor goes away – it just doesn’t take that long to do. When the recipients understand the benefit and realise that the software they are getting is better this way, the time expectation actually adjusts to accommodate for TDD if necessary.

Building a mission critical system badly is setting up for failure. Anyone involved in start-up with a mission critical software dependency should be doing whatever they can to mitigate the risk of the software failing, and all pragmatic means necessary should be taken to deliver a better solution. TDD is a small adjustment developers can make which can pay off enormously.

The initial costs in getting up to speed with TDD can be off putting and maybe some teams drop it. You really need to persevere with it to see the benefits. You can explain this to a developer and they identify with it.

It can often be the non tech voice that can derail the process.

The common argument that TDD is costly is frequently stated as SLOC over time. i.e. If one can produce x SLOC, why have < x production SLOC when it can all be had instead.

The argument makes sense, but falls down with the mistake of assuming SLOC === productivity. In my experience, I have seen a massive increases in productivity when using TDD, brought in due to better design, clearer focus on YAGNI and greater developer confidence. This, I have seen even on new greenfield projects.

If I were a startup I would TDD from the beginning.

However, there is a ramp up to becoming a proficient TDDer, anyone newly adopting TDD can expect their productivity to tank, rising back up while they acclimatise. In the case of an early stage startup without the TDD mindset I would be highly reluctant to recommend it.

You do have a point but as I said in the post I think it’s not so clear cut. I am sceptical of anything that sounds like an absolute!

Cheers

Gareth