Imagine assembling a car engine without any QC process, perhaps just visual inspection of the parts. The end users (whoever will drive the car) will be the actual testers.
You jest, but I have been in a conversation where I proposed a user experience improvement and heard "but if we change the code, it will no longer be tested. Right now, users have reported bugs and we have fixed all of them."
Because users always report bugs...
If you've ever been frustrated by the package manager Conda and the UX of its command-line interface ...I'm sorry. I tried.
It's a trade off. Sure, the ultimate testing is done by customers, but how fast one can push new fixes without tests? 1 reported bug could break many things.
> but how fast one can push new fixes without tests?
Well, if you refuse to write tests and you are scared to make new changes without them... then you can't push new fixes at all. Which is apparently fine for some organizations.
Welcome to the land of ambiguity and subjectivity - enjoy our stay!
The problem is, that there's no way to generally quantify "too much" or "not enough" when it comes to tests and documentation.
Even "harmful" isn't a well defined term on its own and needs to be properly defined on a case-by-case basis.
The statement is a platitude without any substance behind it and you can replace "testing and documentation" with just about anything and come to the same result:
Vitamines and calorie intake are both essential but too much of either becomes harmful.
Because users always report bugs...
If you've ever been frustrated by the package manager Conda and the UX of its command-line interface ...I'm sorry. I tried.