Comment by anileated | Hacker News Reader

Comment by anileated | Hacker News Reader

Parent Full thread

> Code is a liability in the sense that it has a non-zero carrying cost.

The under-appreciated corollary to that: tests are code, hence tests have non-zero carrying cost as well.

> The ideal software implementing a given functionality has as low of a carrying cost as possible. More code, in quantity and complexity, typically means more carrying costs.

You understress the complexity point. Higher quantity of code with high clarity and low complexity would have lower carrying cost. This is where DRY bites people: ill-suited or excessive abstractions can be worse than a little bit of copy-paste that are immediately visible to the eye.

> In this analogy tech debt is a tradeoff for some short term benefit (like simplicity, time to market) at the expense of higher carrying costs down the line.

In a general sense, doesn’t this hold for everything we do? If you really dig into it, is there an activity that is not a trade-off of short-term benefit for higher costs down the line (be it waste, pollution, something unknown or generally entropy)?

Tests are indeed not free. But neither is having to spend two days to debug a weird bug you would have cought if you had them. Depending on the worst thing your software could be doing if it had a edge case mistake, writing tests is also just another take on trying to prevent them when they happen.

Also: nothing prevents us from deleting tests and do as if they never existed, except the nagging voice of sunken cost.

If I've learned anything over my career, it's that tests are treated as write-only code and they forever accumulate. Not only are they a burden in terms of comprehension, they have a measurable cost as your CI/CD pipeline becomes ever slower or requires more parallelism.

I've worked in so many places where a test suite suddenly takes a day to run with no parallelism, and requires 50 other machines to get it down to 20 minutes. And so many of the tests that waste so much time are down to them being pointless, or being stateful for no reason.

I constantly advise people to stop writing obvious bullshit tests (e.g. the kind of test in Rails where you just assert that you wrote `belongs_to :some_model` in your model), or ones that are too heavily mocked. Focus on your business logic and the inputs and intended outputs, not how you used a framework or dependency.

Not all code has equivalent carrying costs. I think the ideal behind tests is that they reduce maintenance costs of the code they cover by more than they add themselves (ideally).

Same as the aim of the original code is to reduce some costs by more than it would add itself. It’s the never-ending game.

Hear hear!!

Reply on news.ycombinator.com