4 ms·

Having a culture of not ever writing tests and actively disallowing them is so insane I can't even imagine why there's anything else in this post

by maplant 7mo ago

oraphalous 7mo ago
[flagged]
- maplant 7mo ago
  Did I say that my way was the right way? No: what I said was actively disallowing tests in every situation was the wrong way. There is no ability here for the cost benefit analysis to change over time. There is only no tests
  - oraphalous 7mo ago
    Did you edit the wording of your original comment slightly to emphasise the "actively disallowing them" in every situation? Anyway... if that is what you meant, then ok. It's less awful a statement than what I felt I originally read. I'd still push back on your hyperbole though. I don't think the author was insane - and we don't know what the broader business context was when they started growing the team and decided to persist without building out the test architecture at that point. They made a call that dogfooding was going to be enough to catch issues as they grew the team. There are a lot of scenarios where that is going to be true. One scenario where it wouldn't - the most likely - is that the team isn't actually dogfooding because they personally don't find the product useful. Leadership lambasts them to use the product more... but no one does cause it sucks so much it impacts their own personal productivity. Even there I wouldn't use the word insane... just poor leadership.
    - maplant 7mo ago
      > Did you edit the wording of your original comment slightly to emphasise the "actively disallowing them" in every situation? I did not.
    - ChrisClark 7mo ago
      He did not edit, and you're misunderstanding the meaning behind his post. Not everything needs to be pedantic and accurate, language is flexible, this is about communicating, not being right. What we really don't need is paragraphs of someone arguing because their own definitions differ slightly from the OP
      - oraphalous 7mo ago
        >He did not edit He edited his reply to me multiple times... which is what made me suspect an edit to the original comment. But whatever, I'm happy to acknowledge his original intent even if he did state it more harshly. >What we really don't need is paragraphs of someone arguing because their own definitions differ slightly from the OP This is unnecessary. OP came out with "AUTHOR IS INSANE" even on the most generous of interpretations. Even if we allow for nuance OP is claiming, there is little constructive about his contribution. I feel fine about calling it out.
        maplant 7mo ago
        > He edited his reply to me multiple times... I got the sense from your reply that some extra clarity would be beneficial. > This is unnecessary. OP came out with "AUTHOR IS INSANE" even on the most generous of interpretations. I did not actually call the author insane, I called their decision to explicitly disallow testing insane. It's an insane decision. I am not _literally_ calling the author insane.
        oraphalous 7mo ago
        > I did not actually call the author insane... If you think this distinction really matters wrt the point I'm trying to make, then it's time for you and I to bug out conversationally. Sometimes two individuals have such different ways of communicating that the pain of exegesis isn't worth the squeeze. No hard feelings. I'm sure 50% responsibility is at least mine, but it's not going to be worth it for either of us figuring out exactly what.
        deleted 7mo ago
- sodapopcan 7mo ago
  The truth is in the middle somewhere, regarding tests at least (yes, your microservices story is insane). I think the author could have been happier with the no-test decision if they had treated the initial work as a prototype with the idea of throwing it away. At the same time, writing some tests, should not be seen as a waste of time since if you're even at all experienced with it, it's going to be faster than constantly reloading your browser or pressing up-up-up-up-up in a REPL to check progress (if you're doing the latter you are essentially doing a form of sorta reverse TDD). So I dunno... I may be more in line with the idea that's a bit insane to prevent people from writing tests BUT so many people are so bad at writing tests that ya, for a go-gettem start up it could be the right call. I certainly agree with your whole cost-benefit analysis paragraph.
- UltraSane 7mo ago
  Not having ANY tests means tons of manual testing is needed every time you modify code, which will rapidly consume more time than writing the tests would.
  - Jtsummers 7mo ago
    The manual tests also stop being run, or get reduced to such an extreme that any value from them is going to be low. Testing only happy paths and maybe release specific tests. This is shockingly (to outsiders, not to anyone who's ever been in the industry) common in aerospace and defense systems. There were some aircraft I would not fly on for a few years until I knew our updates had rolled out. Now I'm not connected to that work anymore so I'm back to "ignorance is bliss" mode and try not to think about it.
- soperj 7mo ago
  > they just stampede in with "THIS IS THE RIGHT WAY". And the discussion can't even be had. That's exactly what this person is railing against. They strictly forbid testing.
  - oraphalous 7mo ago
    Again - that's a business decision that needs to be made in the context of that business. The fact that testing was forbidden isn't in itself good or bad. It depends on that business context. THe post says nothing about how that decision was made, whether it was discussed, or if it was just his absolutist ideal he imposed without consideration of the broader cost-benefit. And I still feel the original comment doesn't give this point enough weight.
    - emil-lp 7mo ago
      Forbidding tests is not a business decision, it's a software engineering decision, and it's a remarkably poor one at that.
      - oraphalous 7mo ago
        Hard disagree. It's both. Choosing one way or the other comes with potential risks and rewards to the business and it's up to business leadership to choose what risks they want to take. Your job as an engineer - if you are not part of leadership is to explain those risks / rewards, and then let them make the call.
        emil-lp 7mo ago
        Okay, yes, that's a hard disagree. I have an education and experience in software development. If a manager told me to make a product in an unsafe manner, I'd refuse, and if push came to shove, leave. Leave, both because I wouldn't be able to defend my work as a professional, but also because I wouldn't work under someone who would want to dictate the manner in which I do what I do.
- hinkley 7mo ago
  > After we started hiring, it became a disaster. When it stopped being two people he still forbade tests. In this decade. That is fucking nuts. Fun fact: the guy I worked a 2 man project with and I had a rock solid build cycle, and when we got cancelled to put more wood behind fewer arrows, he and I built the entire CI pipeline. On cruisecontrol. And if you don’t know what that is, that is Stone Age CI. Literal sticks and rocks. Was I ahead of a very big curve? You bet your sweet bippy. But that was more than twenty years ago.
  - oraphalous 7mo ago
    Did anyone here actually look at the product they were actually building? It's an AI agent bug discovery product. Their whole culture is probably driven at a fundamental philosophical level about the problems of bug discovery. As he says: he wanted to rely on dogfooding - using their product as the way of spotting bugs. That may have been spectactular naivete but it's not insanity. The point I keep coming back to here that everyone is fighting me so hard on is that these blanket statements of: NO TESTS IS NUTS... absent of an understanding of the business context... is harmful.
    - hinkley 7mo ago
      What ends up happening is that your most fundamental features end up rotting because manual testing has biases. Chief among them is probably Recency Bias. It is in fact super easy to break a launch feature if it’s not gating any of the features you’re working on now. If you don’t automate those, yes, you’re nuts. One of the worst ones I ever encountered was learning that someone broke the entire help system three months prior, and nobody noticed. Because developers don’t use the help system. I convinced a team of very skeptical people that E2E testing the help docs was a higher priority than automating testing of the authentication because every developer used that eight times a day or more. In fact on a previous project with trunk based builds, both times I broke login someone came to tell me so before the build finished. Debugging is about doing cheap tests first to prune the problem space, and slower tests until you find the culprit. Testing often forgets that and will run expensive tests before fast ones. Particularly in the ice cream cone. In short, if you declare an epic done with zero automation, you’re a fucking idiot.
- kerkeslager 7mo ago
  > If you are a two man startup, burning through runway and pre-product-market fit... then spending a lot of time on tests is questionable (although the cost-benefit now with AI is changing very fast). What's insane that people in 2026 still think tests slow you down. It takes me maybe 40 hours (1 week) of coding to start receiving ROI from writing tests in a greenfield project, and by 80 hours I'm pretty sure I've saved more time from bugs and improved design due to TDD than I've spent writing the tests. The ROI is even faster if I'm not the only developer on the project. If your flagship product takes less time to develop than 40 hours, then your product is extremely vulnerable to being copied by another company, so your entire software project is a bad business idea. So there really aren't many exceptions: either your project benefits from tests, or it's too easy a project to be a business. So frankly, it's your comment lacking in cost/benefit analysis.
torben-friis 7mo ago
And particularly the “no tests go faster”. I feel like we keep having to reestablish known facts every two years in this field.
- hinkley 7mo ago
  I ran into some serious struggles when we got far enough into accepting most of the tenets of XP as standard practice that most jobs didn’t even debate half of them and then landed at places that still thought they were stupid. I’d taken for granted I wasn’t going to have to fight those fights and forgotten how to debate them. Because I Said So is not a great look.
paulhebert 7mo ago
[flagged]
deleted 7mo ago
[deleted]

Having a culture of not ever writing tests and actively disallowing them is so insane I can't even imagine why there's anything else in this post

by maplant 7mo ago

Having a culture of not ever writing tests and actively disallowing them is so insane I can't even imagine why there's anything else in this post

oraphalous 7mo ago

[flagged]

maplant 7mo ago
Did I say that my way was the right way? No: what I said was actively disallowing tests in every situation was the wrong way. There is no ability here for the cost benefit analysis to change over time. There is only no tests
- oraphalous 7mo ago
  Did you edit the wording of your original comment slightly to emphasise the "actively disallowing them" in every situation? Anyway... if that is what you meant, then ok. It's less awful a statement than what I felt I originally read. I'd still push back on your hyperbole though. I don't think the author was insane - and we don't know what the broader business context was when they started growing the team and decided to persist without building out the test architecture at that point. They made a call that dogfooding was going to be enough to catch issues as they grew the team. There are a lot of scenarios where that is going to be true. One scenario where it wouldn't - the most likely - is that the team isn't actually dogfooding because they personally don't find the product useful. Leadership lambasts them to use the product more... but no one does cause it sucks so much it impacts their own personal productivity. Even there I wouldn't use the word insane... just poor leadership.
  - maplant 7mo ago
    > Did you edit the wording of your original comment slightly to emphasise the "actively disallowing them" in every situation? I did not.
  - ChrisClark 7mo ago
    He did not edit, and you're misunderstanding the meaning behind his post. Not everything needs to be pedantic and accurate, language is flexible, this is about communicating, not being right. What we really don't need is paragraphs of someone arguing because their own definitions differ slightly from the OP
    - oraphalous 7mo ago
      >He did not edit He edited his reply to me multiple times... which is what made me suspect an edit to the original comment. But whatever, I'm happy to acknowledge his original intent even if he did state it more harshly. >What we really don't need is paragraphs of someone arguing because their own definitions differ slightly from the OP This is unnecessary. OP came out with "AUTHOR IS INSANE" even on the most generous of interpretations. Even if we allow for nuance OP is claiming, there is little constructive about his contribution. I feel fine about calling it out.
      - maplant 7mo ago
        > He edited his reply to me multiple times... I got the sense from your reply that some extra clarity would be beneficial. > This is unnecessary. OP came out with "AUTHOR IS INSANE" even on the most generous of interpretations. I did not actually call the author insane, I called their decision to explicitly disallow testing insane. It's an insane decision. I am not _literally_ calling the author insane.
        oraphalous 7mo ago
        > I did not actually call the author insane... If you think this distinction really matters wrt the point I'm trying to make, then it's time for you and I to bug out conversationally. Sometimes two individuals have such different ways of communicating that the pain of exegesis isn't worth the squeeze. No hard feelings. I'm sure 50% responsibility is at least mine, but it's not going to be worth it for either of us figuring out exactly what.
        deleted 7mo ago
sodapopcan 7mo ago
The truth is in the middle somewhere, regarding tests at least (yes, your microservices story is insane). I think the author could have been happier with the no-test decision if they had treated the initial work as a prototype with the idea of throwing it away. At the same time, writing some tests, should not be seen as a waste of time since if you're even at all experienced with it, it's going to be faster than constantly reloading your browser or pressing up-up-up-up-up in a REPL to check progress (if you're doing the latter you are essentially doing a form of sorta reverse TDD). So I dunno... I may be more in line with the idea that's a bit insane to prevent people from writing tests BUT so many people are so bad at writing tests that ya, for a go-gettem start up it could be the right call. I certainly agree with your whole cost-benefit analysis paragraph.
UltraSane 7mo ago
Not having ANY tests means tons of manual testing is needed every time you modify code, which will rapidly consume more time than writing the tests would.
- Jtsummers 7mo ago
  The manual tests also stop being run, or get reduced to such an extreme that any value from them is going to be low. Testing only happy paths and maybe release specific tests. This is shockingly (to outsiders, not to anyone who's ever been in the industry) common in aerospace and defense systems. There were some aircraft I would not fly on for a few years until I knew our updates had rolled out. Now I'm not connected to that work anymore so I'm back to "ignorance is bliss" mode and try not to think about it.
soperj 7mo ago
> they just stampede in with "THIS IS THE RIGHT WAY". And the discussion can't even be had. That's exactly what this person is railing against. They strictly forbid testing.
- oraphalous 7mo ago
  Again - that's a business decision that needs to be made in the context of that business. The fact that testing was forbidden isn't in itself good or bad. It depends on that business context. THe post says nothing about how that decision was made, whether it was discussed, or if it was just his absolutist ideal he imposed without consideration of the broader cost-benefit. And I still feel the original comment doesn't give this point enough weight.
  - emil-lp 7mo ago
    Forbidding tests is not a business decision, it's a software engineering decision, and it's a remarkably poor one at that.
    - oraphalous 7mo ago
      Hard disagree. It's both. Choosing one way or the other comes with potential risks and rewards to the business and it's up to business leadership to choose what risks they want to take. Your job as an engineer - if you are not part of leadership is to explain those risks / rewards, and then let them make the call.
      - emil-lp 7mo ago
        Okay, yes, that's a hard disagree. I have an education and experience in software development. If a manager told me to make a product in an unsafe manner, I'd refuse, and if push came to shove, leave. Leave, both because I wouldn't be able to defend my work as a professional, but also because I wouldn't work under someone who would want to dictate the manner in which I do what I do.
hinkley 7mo ago
> After we started hiring, it became a disaster. When it stopped being two people he still forbade tests. In this decade. That is fucking nuts. Fun fact: the guy I worked a 2 man project with and I had a rock solid build cycle, and when we got cancelled to put more wood behind fewer arrows, he and I built the entire CI pipeline. On cruisecontrol. And if you don’t know what that is, that is Stone Age CI. Literal sticks and rocks. Was I ahead of a very big curve? You bet your sweet bippy. But that was more than twenty years ago.
- oraphalous 7mo ago
  Did anyone here actually look at the product they were actually building? It's an AI agent bug discovery product. Their whole culture is probably driven at a fundamental philosophical level about the problems of bug discovery. As he says: he wanted to rely on dogfooding - using their product as the way of spotting bugs. That may have been spectactular naivete but it's not insanity. The point I keep coming back to here that everyone is fighting me so hard on is that these blanket statements of: NO TESTS IS NUTS... absent of an understanding of the business context... is harmful.
  - hinkley 7mo ago
    What ends up happening is that your most fundamental features end up rotting because manual testing has biases. Chief among them is probably Recency Bias. It is in fact super easy to break a launch feature if it’s not gating any of the features you’re working on now. If you don’t automate those, yes, you’re nuts. One of the worst ones I ever encountered was learning that someone broke the entire help system three months prior, and nobody noticed. Because developers don’t use the help system. I convinced a team of very skeptical people that E2E testing the help docs was a higher priority than automating testing of the authentication because every developer used that eight times a day or more. In fact on a previous project with trunk based builds, both times I broke login someone came to tell me so before the build finished. Debugging is about doing cheap tests first to prune the problem space, and slower tests until you find the culprit. Testing often forgets that and will run expensive tests before fast ones. Particularly in the ice cream cone. In short, if you declare an epic done with zero automation, you’re a fucking idiot.
kerkeslager 7mo ago
> If you are a two man startup, burning through runway and pre-product-market fit... then spending a lot of time on tests is questionable (although the cost-benefit now with AI is changing very fast). What's insane that people in 2026 still think tests slow you down. It takes me maybe 40 hours (1 week) of coding to start receiving ROI from writing tests in a greenfield project, and by 80 hours I'm pretty sure I've saved more time from bugs and improved design due to TDD than I've spent writing the tests. The ROI is even faster if I'm not the only developer on the project. If your flagship product takes less time to develop than 40 hours, then your product is extremely vulnerable to being copied by another company, so your entire software project is a bad business idea. So there really aren't many exceptions: either your project benefits from tests, or it's too easy a project to be a business. So frankly, it's your comment lacking in cost/benefit analysis.

torben-friis 7mo ago

And particularly the “no tests go faster”. I feel like we keep having to reestablish known facts every two years in this field.

hinkley 7mo ago
I ran into some serious struggles when we got far enough into accepting most of the tenets of XP as standard practice that most jobs didn’t even debate half of them and then landed at places that still thought they were stupid. I’d taken for granted I wasn’t going to have to fight those fights and forgotten how to debate them. Because I Said So is not a great look.

paulhebert 7mo ago

[flagged]

deleted 7mo ago

[deleted]