4 ms·

I'd argue a function of scale as well as a function of criticality. Not all projects need the same level of care put into them as the blast radius of bugs is...

I'd argue a function of scale as well as a function of criticality. Not all projects need the same level of care put into them as the blast radius of bugs is... negligible sometimes

marginalia_nu 3y ago
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.
- robertlagrant 3y ago
  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.
- facundo_olano 3y ago
  (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.
- chefandy 3y ago
  Beneficial processes without sanity checks become dogma.
bcrosby95 3y ago
And function of ease of manual testing. Some things are impossible to manually test without changing the actual code. For example, testing access permissions. Your UI isn't gonna display data or operations you don't have access to. But that doesn't mean your back end is honoring permissions. The other thing to take into account is how noticable the bug is. You should inch more towards writing tests for bugs that are less likely to be noticed by someone.

I'd argue a function of scale as well as a function of criticality. Not all projects need the same level of care put into them as the blast radius of bugs is... negligible sometimes

marginalia_nu 3y ago

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.

robertlagrant 3y ago
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.
facundo_olano 3y ago
(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.
chefandy 3y ago
Beneficial processes without sanity checks become dogma.

bcrosby95 3y ago

And function of ease of manual testing. Some things are impossible to manually test without changing the actual code. For example, testing access permissions. Your UI isn't gonna display data or operations you don't have access to. But that doesn't mean your back end is honoring permissions. The other thing to take into account is how noticable the bug is. You should inch more towards writing tests for bugs that are less likely to be noticed by someone.