Hacker News Reader

Comment by marginalia_nu | Hacker News Reader

For larger projects, even trivial bugs can waste an enormous amount of time, since the number of places they can hide is much larger, and fixing them may mean blocking other work. Means that at such a scale, optimizing for correctness at all times makes sense.

In a small project where bugs are easy to identify and tend to be an easy 10 minutes fix, foregoing the correctness tax and fixing bugs as they become apparent is the more economic choice.

View on HN

(I'm the post author). I agree with this. Perhaps I'd emphasize larger in terms of people working on it rather than codebase size. Once you have competing "mental models" about how the code works, the problem of silent bugs can escalate quickly.

So I do think the "always test" mentality is a reasonable default for the non-prototype type of work. There's a tipping point where going on without testing can get the project out of control and it's hard to tell when that is, so in contexts where you care to avoid that risk it makes sense to be strict about it. I didn't care for that risk in this case, so it made sense not to bother and focus on building momentum. I'd probably add some integration tests now if I wanted to try a significant new feature or refactor, or if I had to consider contributions from other developers.

The inverse is true as well: for a project regardless of size that's part of a medical device, the economic choice isn't allowed for certain classes of bug.

Beneficial processes without sanity checks become dogma.

Reply on news.ycombinator.com