> In fact, I expect the "why" 99% of the time is "I felt like it and it worked".
Erm, we're talking about professional software development here.
What someone is tinkering together in his hobby cellar is of no interest to me.
Code created by the principle "I felt like that" is garbage by definition. It makes no sense to even discuss such stuff.
> When a specific approach is essential in meeting certain application requirements, absolutely you need to comment that. But you also need tests, else how are you going to ensure that you stay within those requirements? Of an application of any meaningful size, you're going to have a hard time manually ensuring that some externality didn't break your assumption on every deploy. Even if it weren't hard, why put in the man hours when a machine can do it for you?
Here I actually agree fully.
What can be tested by the machine should be.
That's for example a reason to use statically languages, as in contrast to such thing as Ruby, the machine can give much better correctness guaranties with static type checking.
But the point is: Not everything can be expressed as meaningful test.
For example you proposed something that would result in a flaky test case…
Some other things can't be expressed as test either. And the experience shows that's this things are almost always related to the why question. In the end you put exactly this question front while discussing some imaginary implementation of something, which shows my point nicely. :-)
> Code created by the principle "I felt like that" is garbage by definition. It makes no sense to even discuss such stuff.
I think you are vastly overestimating not only how much people do work rationally, but how much it's even possible. E.g., System 2 thinking is just much more expensive. And programmers usually work in environments that are pretty data-poor with respect to important factors. And that's before we even get to both project-level and individual path-dependence.
Erm, we're talking about professional software development here.
What someone is tinkering together in his hobby cellar is of no interest to me.
Code created by the principle "I felt like that" is garbage by definition. It makes no sense to even discuss such stuff.
> When a specific approach is essential in meeting certain application requirements, absolutely you need to comment that. But you also need tests, else how are you going to ensure that you stay within those requirements? Of an application of any meaningful size, you're going to have a hard time manually ensuring that some externality didn't break your assumption on every deploy. Even if it weren't hard, why put in the man hours when a machine can do it for you?
Here I actually agree fully.
What can be tested by the machine should be.
That's for example a reason to use statically languages, as in contrast to such thing as Ruby, the machine can give much better correctness guaranties with static type checking.
But the point is: Not everything can be expressed as meaningful test.
For example you proposed something that would result in a flaky test case…
Some other things can't be expressed as test either. And the experience shows that's this things are almost always related to the why question. In the end you put exactly this question front while discussing some imaginary implementation of something, which shows my point nicely. :-)