There is common confusion about what the default position is on many topics if the other side has yet to provide icon-clad evidence. Logically, the default is "unknown" or "null". Each side is obligated to provide sufficient evidence to shift it away from "unknown".
For example, it's common in ID circles to say that evidence against evolution, such as the relatively sudden Cambrian Explosion, is evidence of ID because evolution still has gaps or holes. However, that excludes the possibility of 3 or more possibilities (such as robots created all or time recursion did it). Thus, gaps in evolution are not by themselves strong evidence for ID. It's quite possible for two or more theories to be weak or have gaps.
(It is strong evidence if one can prove that there are only two possible theories, and one has evidence against one of the two.)
Please note the point of ID is that natural evolution never passed any realistic test of evidence in accordance with the rules that those who now back it would say would have to be met by any that would replace it. From a historical perspective, ID is the null hypothesis. Nobody knows what happens from DefaultStanceIsUnknown because nobody's willing to play on a level playing field.
[The stance which is commonly accepted in fact actually is the default, but it's not an ArgumentFromPopularity, because it's not an argument. One presumes that others believe that which is commonly accepted as a starting point to convince them of whatever it is one wishes to convince them of; this doesn't at any point involve an argument or even an assumption that that which is commonly accepted is true, so no ArgumentFromPopularity arises (in fact, from the arguer's perspective, that which is commonly accepted must naturally be false, otherwise one would have no reason to change others' minds!). When one makes an exceptional claim{[1]}---meaning one that is distinct from that which is commonly accepted---one then has a BurdenOfProof to demonstrate one's claim and hopefully convince others to change their opinions and views. It's fallacious (ShiftingTheBurdenOfProof) instead to demand evidence that others prove that that which is commonly accepted is true. This is how argument and debate work; it's not me or anyone else inventing fictional debate rules, and it's not contrary to rational logic in the slightest. -DavidMcLean?]
How is that not ArgumentFromPopularity? I'm still not clear on how you recon that. It is an "assumption". Formal debate rejects ArgumentFromPopularity and ArgumentFromAuthority. The "real world" is more nebulous on that; but in the real world its also "reasonable" to ask, "why do most people say that?" and expect evidence. Myths and "wives tales" are common and commonly wrong and it's acceptable to ask for verification before relying on them, at least in the "educated" world. -t
[It's not ArgumentFromPopularity because it's not an argument. One is merely presuming that others currently believe that which is commonly accepted. That isn't an argument that that which is commonly accepted is true; indeed, you're trying to prove that that which is commonly accepted is false, so it'd be foolish to start out by arguing that that which is commonly accepted is true. You'd do better to argue that whatever you're trying to prove is true, preferably with supporting evidence. -DavidMcLean?]
Presuming is bad form. Yes, and "do better to" may indeed be better, but is not necessary. It would be orgasmically nice to have an OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy to defend ones position, but just because it's not available does not automatically make the other candidate position(s) the default "truth".
[Correct. It doesn't. The other candidate's position is that which is commonly accepted, however, which leaves the BurdenOfProof on you, regardless of which position is true. Truth is in fact irrelevant. -DavidMcLean?]
Sorry, you have not justified that clearly. Popularity does not get you off the hook from defending your (popular) opinion.
[We don't assume that that which is commonly accepted is true---that would be fallacious---but we do require evidence to shift our stance from that which is commonly accepted, because demanding the opposite would also be fallacious. -DavidMcLean?]
[Urban myths often aren't that which is commonly accepted. Regardless, what the MythBusters? do is exactly as I just said: They gather evidence to shift the viewers' beliefs from the myth to reality. Notice that they don't demand that others give them proof? - DavidMcLean?]
Sure, but you are not doing that.
[Neither are you. You're demanding that I provide proof of that which is commonly accepted, rather than providing proof of your own perspective, one that is not. -DavidMcLean?]
I am only obligated if there are only two possibilities. For example, if you claim that one should "always group code by X", I am NOT obligated to provide evidence that it should be grouped by Y or any other letter. The "X is better" claim is your claim and your obligation. (If you give me a specific example, I'd be happy to suggest other possibilities to measure and compare.)
I'm going to disagree (to some extent) with both the above participants. What the default stance is (or even if it exists) will depend on circumstances. If one is trying to change someones mind about an issue, then the default stance is clearly what that person already believes. In some forms of formal debate, there simply isn't a default stance. If you don't support your argument, your argument is invalid. In science, the situation is usually closer to the former. Most of the time, there is some incumbent theory that is considered correct. It's up to competing theories to offer some sort of advantage over the incumbent.
[Absolutely. In the context we're working from, though, there does happen to be an incumbent theory in place, so alternative theories will need support and evidence. -DavidMcLean?]
In the context we are working from, there is no hard survey data (and I suspect the answer will depend on how the survey is written such as "always" versus "usually" versus "often"). But anyhow, EVERY position needs to defend itself. There is no "king of the kill" except that theory with the most evidence, NOT the most votes. In science, the "incumbent theory" is usually that one with the most evidence backing it. If new evidence comes along that overwhelms the former, then it becomes the leading horse. But the leading horse is not the same as the standing champ, the race continues. True, in science it often takes a while for the new theory to bounce around in the establishment before the strength is collectively realized, but that's a property of people, not of truth itself.
[Sure, but the incumbent theory isn't invalidated simply because someone offers another theory. That other theory must in fact come with evidence that does indeed overwhelm that presented by the incumbent theory, and your presented theories are lacking in evidence. -DavidMcLean?]
Your inability to demonstrate such with sample code suggests that isn't the case. The reader has no way to verify your claim of both success and commonness. But let's try to leave the "presentation" subject in that topic.
{The content on the originating page provides both essential code and rationale. You simply don't agree with it.}
"Essential"? Never mind, I won't ask this time.
{As in, "the essence of", not as in "required".}
The essence is "fuzziness" there.
{To you alone, it seems.}
More fake surveys of the non-masses?
{This page originated from one in which you argued against unconditional SeparationOfConcerns along functional boundaries (as opposed to "change pattern" boundaries) and against division of business logic and presentation logic. In SoftwareEngineering, these are universally accepted ways of achieving good coupling and cohesion, which are themselves universally accepted notions. No surveys are needed -- all it takes is to read any text on programming, look at any development tool documentation, examine enterprise software product architecture, talk to developers, and simply be aware of industry trends over the past few decades. These notions have been tested in practice over and over and over again -- every successfully implemented application is proof of their validity, especially if compared to every beginning developer's first stabs at large-scale development. You are the only developer I know to not only question these practices, but to argue against them. However, if alternatives to these fundamental notions are to be successfully fielded, it will not come from a lone dissenting voice. And I think I'm quite justified in "lone", as I don't see anyone here or anywhere else questioning SeparationOfConcerns as described above. It will only come from overwhelming evidence that the alternatives are superior.}
{In short, we don't have to defend what we know works, because it works. If you want to be heard, it's up to you to prove that there are alternatives that work better. Otherwise, we'll get back to writing code -- using what we know works -- and ignore you.}
If such textbooks exist, quote and cite them. ItDepends is a universally excepted notion. I truly doubt the sources you believe exist say "always do X". And I hope they define stuff better than you, Mr. SuperExperiencedYetSuperFuzzy?. Perhaps we can make some kind of bet where the loser has to translate something into working BrainFsck code. You make shit up.
{Less than 10 seconds searching reveals https://web.cs.dal.ca/~sedgwick/3132/slides/notcovered/chap02.pdf See page 27.}
{Oh, here's another: http://books.google.co.uk/books?id=pFHYk0KWAEgC&pg=PA85&dq=%22separation+of+concerns%22&hl=en&sa=X&ei=WQ_aUNn5DYjNiwLS54GADQ&redir_esc=y#v=onepage&q=%22separation%20of%20concerns%22&f=false }
{Now, can you find texts that advocate against SeparationOfConcerns, coupling and cohesion, etc.? If not, I see no reason to continue this, as you're obviously not intending to present any evidence for something superior to SeparationOfConcerns along functional boundaries and against division of business logic and presentation logic. Therefore, you're a lone time-waster and not worth any attention.}
I don't see any concrete coded biz scenarios with maintenance metrics. (It does have a baggage handling app example, but we are not permitted see it all. I don't see where it attempts to compute and compare future maintenance cost.) And again again again, I am NOT against SOC in GENERAL. You are putting words in my mouth. You are a very frustrating and evasive human being and I am resisting some really nasty language right now. (I find it reasonable from an economic standpoint to partition code along likely future maintenance patterns as apposed to "always do X because my clique says so".) Related: CouplingAndCohesion.
{"Concrete coded biz scenarios" are not always required, but if you feel they are, please provide "concrete coded biz scenarios" demonstrating how you "partition code along likely future maintenance patterns".}
Yes, it's needed because English is vague or ambiguous. I explored a coded example already in BusinessLogicDefinitionDiscussion.
{It's a toy example. Please provide a realistic application.}
If you want a 30,000 line app to dissect, sorry I don't have one I can present.
The implications of leaving (alleged) "best practices" unchallenged would mean there is almost no purpose for an open wiki; the conversation ends when somebody claims/establishes "best practice" via vote counting/surveys. There is no incentive to dissect "best practices" to verify them and/or figure out why they are the best. That is 1300's thinking. It will stymie our field (or perhaps explains why it is already stymied.) -t
There is no problem in challenging best practices. The problem discussed here is making the argument, "My way is just as good as yours unless you prove otherwise." and not providing evidence for that.
No, usually it's the case of "provide justification for doing X". Whether Y is better than X is immaterial to the need to provide justification for X. Your characterization is thus wrong.
{Our justification for X may be (and is, in the originating case) experiential. In short, it works for us. If you wish to challenge that, you need to provide a strong justification for doing Y. Otherwise, we'll ignore you and continue doing X because X works for us.}
Both sides often have such. You are putting your experience at the center of the universe.
[In a world where uncertainty far outpaces certainty, the first step is to establish consistency. Once you have consistent practices you can begin to measure the effect of switching X to Y. However, until the whole team is doing X consistently, you'll just be throwing mud in each others' eyes. It's better to do something now that's GoodEnough than that which is JustRight? but too late.]
I agree there can be various degrees of QwertySyndrome where multiple parties and technologies have to change together to be effective. But proponents of certain practices generally claim something is "clearly better", not that there is safety in stability. They are over-hyping their position.
Compromise?
Maybe we can find a balance between formal debate rules and "street science" whereby challengers to the incumbent (common use) require a somewhat higher level of evidence than the incumbent. However, the incumbent is not free of the burden to provide evidence. The supporters of the incumbent do not automatically get to claim "it's better", only that it's street-tested enough to verify it at least doesn't suck too much. Otherwise, we'd be stuck with the flat-Earth model and GoTo's.
Footnotes
[1] Note that I am not making an "exceptional claim" in BusinessLogicDefinitionDiscussionTwo, the topic which spawned this, as explained there. Your measurement of "exceptional" is wrong. But for the sake of argument, let's assume it is. -t
[It's not wrong, but your understanding of "exceptional" might be. Your claim is exceptional merely because it differs from that which is commonly accepted, and nothing more. This isn't a value judgement on your claim, so arguing that it's unexceptional isn't a worthwhile subject. -DavidMcLean?]
"Always do it" is the minority viewpoint. ItDepends is commonly accepted by most people in IT. We probably just disagree with the amount of "acceptable" deviations.
CategoryEvidence, CategoryDiscussion