Hacker News Reader

Comment by PhilWright | Hacker News Reader

A multiple of 100x the cost to fix a bug in production compared to development is very context dependent. These examples always assume your working on a large project with many developers and complex testing and deployment processes.

But there are many developers, like myself, that work on relatively small projects in small teams. The multiple is more like 5x or less for these scenarios. My current project is developed by two of us and deployed to just a couple of dozen users inside our company. I can walk to a users computer, be shown the bug, fix and test it on my machine and deploy it in minutes. Do I need TDD and Code Reviews? Will it pay back all the extra time? I would argue not. One size does not fit all. Sometimes it is appropriate but sometimes not. I hate this type of article, claiming their way should be adopted by everyone all the time. Context is everything!

View on HN

I have found that small teams in small companies are more vulnerable to critical failures personally. That doesn't mean that the TDD mantra needs to be followed word for word but covering your core functionality with test cases allows you to manage risk and getting another set of eyes on the problem tends to pick up obvious problems you are blinkered to. It also enables large changes to take place effectively whic is a big problem when you have very few people working on a project. Without coverage you end up with something people are afraid to change which means every fix is snowballing it into a muddy mess because the shortest path is taken, not the most architecturally sound solution.

While defects happen, it's massively more expensive to handle them with the end user even if they are in the same office. You're costing their time as well as yours.

I'm middle of the road but I'd rather sleep easy knowing my ass is covered at least.

This experience comes from watching a company fail miserably due to their internal software failing. It cost a rewrite in the end which the company couldn't foot the bill for so spiralled into decline. Massive cock up and bad failure mode but a real one I'm afraid.

> Do I need TDD and Code Reviews? Will it pay back all the extra time, much of it wasted? I would argue not. One size does not fit all.

Agree with this for the same reason I wouldn't advocate formal verification for every project. You have to weight up the benefit-cost ratio. For example, if it's the kind of project where you really can keep most of the behaviour in your head, you're not expecting to make many changes to it later or the chance + impact of production bugs is low, TDD is probably going to cost you. TDD for a MVP probably isn't worth it for instance when you're not really sure what you're designing yet and it might be short lived.

> I can walk to a users computer, be shown the bug, fix and test it on my machine and deploy it in minutes.

There's a few assumptions here. The first is that the user will recognize it as a bug and call you straight away, they could try several times before realizing this, which could be time consuming. There is also your time being waste be being called over for any potential bug.

And that's assuming the bug is noticeable, an edge case in your program could result in bad data being fed into another system. In that case your bug might not be noticed for months (or never) in which case trying to track down the source of the error is a much bigger problem.

> Do I need TDD and Code Reviews? Will it pay back all the extra time?

There is actually a better question. Why do I need TTD/Code Reviews/Whatever? And the followup question is: Will that give me the benefit I expect? And the final follow up is: Is there anything else that will give me that same benefit.

I'm going to say that I like TDD - a lot. But one doesn't just do TDD (to exploit a meme). One does TDD for a reason. If your reason is "because I want to make sure my code works", then I can point to a large number of other techniques that will help as much or better. There are other reasons to do TDD, some of which have very few alternatives.

I don't want to write a book on TDD here. My point is that if you are delivering software and being successful, then why would you look for a solution to a problem you don't have? It may be that TDD can help you, but nothing will come of it until you can see the underlying problem for which TDD is your solution.

So, yes, I agree. If you see no reason to use TDD, it would be pretty crazy to do it.

What if one leaves the team and the new members find it hard to make any changes without creating a few extra bugs?

Entropy is hard enough to fight, and without documentation or tests, I think, the software is doomed.

Reply on news.ycombinator.com