I personally hate working with people who put things in terms of 'right' and 'wrong', or 'correct' and 'incorrect'.
I honestly believe the key to software development is good decision making. If you're thinking in terms of right and wrong, correct and incorrect, then you're not making decisions, you're simply doing the right thing over and over again. Only it may not be the OPTIMAL thing, or the smart thing, in any specific instance.
For example, who here really believes proponents of unit tests have never painted themselves into a corner? How did that happen? By making poor decisions.
Stop thinking in terms of right and wrong. Seriously. Sometimes unit tests are a good decision, sometimes they're not. Sometimes that hack is a good decision, and sometimes it isn't.
You make a decision on a case by case basis, not because it's right.
> I honestly believe the key to software development is good decision making.
I agree, and the purpose of my comment was to point out that I have often observed people making decisions on a case by case basis, and repeatedly making bad decisions by underestimating how much effort the solution thought to be 'quicker' or 'easier' or 'minimal change' option is compared to the solution thought to be more 'radical' or 'unnecessary effort'.
You seem to have some specific bone to pick around testing. I'm not really interested in that. When I say 'right' or 'correct' in this context, it's generally about not being blinkered by the current state of your codebase. People get so used to the fact that their current codebase does things in a particular way, they often look at problems as situations where they have no choice but to force the problem into the frame of their code. Solutions where you solve the problem with something closer to what you would want to write if you didn't have to worry quite so much about the peculiarities of your current codebase generally scare people, but are often the better decision not just from some academic point of view, but literally from an execution, getting-things-done quickly point of view. 'correct' as I use it in this context is mainly a shorthand for that concept.
The whole point here is not to say that there's some secret that avoids you from having to make decisions, it's to say that many people in the real world are making a particular class of error in decision making. Signs that a particular decision might fall in that category include:
1. the main trade off being considered between the options is developer time
2. none of the developers actually think the believed-to-be-quicker-to-implement option is a good option apart from its supposed quickness to implement.
3. other options exist where a significant fraction of developers agree that apart from their supposed slowness to implement, they are good options.
I like the idea of finding a good decision in the context of a current situation. I don't like the idea that terms like 'correct' and 'incorrect' should not be used. For some problems, there exist exactly correct solutions (like adding integers). The lack of a well-founded or at least well-known correct solution is what forces you to look for an optimal solution made of trade-offs.
I honestly believe the key to software development is good decision making. If you're thinking in terms of right and wrong, correct and incorrect, then you're not making decisions, you're simply doing the right thing over and over again. Only it may not be the OPTIMAL thing, or the smart thing, in any specific instance.
For example, who here really believes proponents of unit tests have never painted themselves into a corner? How did that happen? By making poor decisions.
Stop thinking in terms of right and wrong. Seriously. Sometimes unit tests are a good decision, sometimes they're not. Sometimes that hack is a good decision, and sometimes it isn't.
You make a decision on a case by case basis, not because it's right.