That's exactly what this person is railing against. They strictly forbid testing.
And I still feel the original comment doesn't give this point enough weight.
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.
There is no ability here for the cost benefit analysis to change over time. There is only no tests
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.
I did not.
What we really don't need is paragraphs of someone arguing because their own definitions differ slightly from the OP
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.
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.
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.
To argue with your actual point: I don't really care about the overall context, actively disallowing tests in a codebase is a _bad decision_. Look how it worked out for them.
> it's time for you and I to bug out conversationally
Fine with me
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.
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.
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.
It's not that I disagree with you essentially - or particularly with respect to your analysis of your specific examples. 100% in the cases you describe. Those sound like beneficial tests. Particularly because your example SPEAKS to the business case - users were using the help docs (I think you mean users anyway). So yeah - that's important.
But I don't know why it's so hard extracting a simple acknowledgement of what I'm pointing out - specifically that the decisions like implementing tests IS a cost-benefit decision dependent on business context.
Funny you mention auth testing though. One time both me and the tech lead broke one of the auth flows in production within the space of a week of one another. Yep - no tests. Feel free to judge us insane. But here's how we thought about it - and when I say "we" that includes the business. First of all the auth flow was not actually used by any active users, so damage was low. Two man dev team. Complexity up until that point had been low, pre-product market fit, sales were dogshit, and cash had been low for some time. Feature shipping was the 110% priority. Ok - but these bugs were a sign complexity had increased beyond what we could manage without some tests. And given the importance of auth, it was now easy to make the case to leadership that implementing an e2e test suite was worth it. So we did.
If you still think a decision making process like that is insane - because we didn't immediately implement tests for every shipped feature. Well - I just think you're wrong.
It’s clear to me that if you don’t know what you’re building, testing it first has rubber duck value that can easily be overshadowed by Sunk Cost. I always test my pillars - the bits of the problem that are definite and which I will build off of.
Yes, starting with tests without market fit can also be fatal. But calling anything done without tests is just a slower poison. Before you airlift your brain to another unrelated problem you need to codify some of your assumptions. If you’re good at testing you can write them in a manner that makes it easy to delete them when requirements change. But that takes practice a lot of people don’t have because they avoid writing tests or they write the exact same kinds of tests for years at a time without every stretching their skills.
If you’re not writing tests you’re not writing good ones when you do. Testing is part of CI and the whole philosophy of CI is do the painful parts until you either grow callouses or get fed up and file off the scratchy bits. To avoid testing is to forget the face of your father.
https://news.ycombinator.com/item?id=3033446 - Linking to this old comment because it links to each of Ron's articles, a discussion about it, and Norvig's version.