If You Were Smart Enough Youd Just Know

This is a common informal fallacy that I encounter on this wiki in various debates. It appears to be an excuse to not have to provide explicit evidence and explicit logic. Variations include:

If you read all the books I did, you'd just know that X is better or right.
If you where as smart as me, you'd just know that X is better or right.
If you used tool X long enough, you'd just know that X is better or right.
If you knew X well enough, you'd just know what an X is and isn't (definition).

It's a variation of ArgumentFromAuthority. "Just know" implies one will feel the truth in their bones. It almost reminds me of a religious missionary who insists you read their scripture set and then pray, and then (insert your favorite deity) will put the feeling into your body and you'll just feel the truth throughout your body like a kind of electricity. Logic and evidence need not apply.

--top

I appreciate that you perceive it that way, but you're probably misinterpreting one of our great frustrations with you: your inclination to criticise, with obviously little understanding, fields that some of us have spent decades studying in great depth. It has nothing to do with you being as "smart as me", and everything to do with what could be the decades I have spent reading books about 'X', using 'X', and gaining an in-depth education in the subject area to which 'X' belongs. It's rather insulting for you to wander in, with obviously only a glancing familiarity of 'X', and act like you know better or that we should be obligated to defend 'X'.

If your field of study fails to provide you with the tools/knowledge/skills to present clear, direct, and objective evidence related to it, then your field is doing something wrong. The fault is not me, it's the lack of science in your field (or your memory's inability to remember the science-side). Go kick your school, NOT me.

[A lack of comprehension on the reader's part is not a failure on the writer's part when the reader refuses to study a subject in more depth.]

It's quite possible many universities have inadvertently ended up relying too heavily on ArgumentFromAuthority over the years in software fields out of habit and tradition, perhaps because of insufficient criticism. You may have picked up and absorbed this bad habit, and have grown science-blind over time. The field of psychology has even admitted it made a similar mistake (heavily due to difficulty in conducting repeatable science), and is now trying to remedy that. Thus, it does and can happen to fields. -t

It's possible, but you haven't yet demonstrated evidence of it. More likely, you simply don't know enough about the subject to either criticise it intelligently or fully understand the responses to your critique. The job of subject education is not to create a sound-bite defences of it when pointlessly challenged by the deliberately naïve. Your perception of ArgumentFromAuthority is also an apparent product of that deliberate naïvety.

We are usually talking about tools. One does not have to know how cars work to know if car A is "better than" car B. You can't just say "Car B is better because it uses the Groppenheimer spark plug valve (G-valve)" alone. Instead you'd need to explain what practical benefit(s) a G-valve provides to users (car drivers), such as better acceleration. The user (driver) can then verify that claim. Many of your claims do not tie your Magic Trait to something practical. You are missing a step. It's usually ArgumentByElegance, but intellectual "elegance" does not necessary tie to practical benefits.

If the car driver cannot detect any benefits, you are doing the equivalent of chewing out the driver, saying, "You just don't understand Groppenheimer valves! If you did, you'd JUST KNOW the car is better! Your driving tests are only for plebeian dummies!" -t

Your analogy is not quite apt. A better analogy -- if we're sticking with cars and tools -- is a torque angle gauge. It's a tool for ensuring that fasteners -- engine head bolts and the like -- are properly tightened. Mechanical engineers and mechanics use them without much controversy; their application is well-understood, and their users happily apply them as they see fit, occasionally discussing their use on a forum for mechanical engineers and mechanics.

Now you come along -- perhaps with some basic mechanical knowledge, but you're neither a mechanical engineer nor a full-time mechanic -- and claim that torque angle gauges aren't necessary: they're a specialist tool only used "out of habit and tradition, or perhaps because of insufficient criticism." We shouldn't use them; anyone can tighten fasteners just fine with an ordinary torque wrench.

We calmly point out that a torque angle gauge is more accurate because it isn't affected by friction, and being more accurate when tightening bolts means less chance of an assembly warping, being damaged, or coming loose.

You reply that in the many years you've been repairing clocks, you've never warped or damaged an assembly, or had anything come loose. We point out that we're talking about much more than clocks; under specialist vehicle applications -- for example -- like racing or other extreme conditions, the risk of warping, damage, or inadvertent disassembly is increased. You say extreme conditions are rare; everyone has at least one clock, and no one needs a torque angle gauge to fix a clock. We point out that there are more extreme conditions than you think -- like driving in stop-and-go traffic or winter cold snaps -- that can affect car engines. You point out that you're talking about clocks, not car engines, and whilst maybe there are rare circumstances where a car engine needs to be repaired, you're not talking about car engines and we haven't proven that torque angle gauges are needed to fix clocks.

We point out that clock repair might seem important to you, but it's actually one mechanical repair niche among many. Almost everyone drives a car that will need it repaired at some point, and that repair could well benefit from a torque angle gauge. You ask us to prove it or retort with "so you say," or assert that there are no real practical benefits to torque angle gauges -- it's just ArgumentFromAuthority if we reference recognised sources or ArgumentByElegance if we say it's better to be more accurate than less accurate. Anyway, you say, real-world bolts don't need to accuracy of a torque angle gauge and the typical mechanic doesn't know how to read them.

We point out that you obviously lack knowledge of mechanical engineering or mechanics and engine repair. You claim that most car repair is done by non-mechanics in their garages, so we need to target our tools at them and we should be able to "present clear, direct, and objective evidence" -- that can be understood by non-mechanics -- in favour of torque angle gauges.

The discussion goes rapidly downhill from there. Eventually, it winds up being reconstituted as a stylised example in some meta-discussion page.

Part of this argument sounds like a case of TheRightToolForTheJob. I don't claim my favorite tools or techniques are the best for every niche and domain usage.

For many years, you did claim that TableOrientedProgramming was the best for every niche and domain usage. I'm glad you've softened on that stance, but you've replaced it with a new kind of adamant dogmatism against tools like (e.g.) HigherOrderFunctions.

Moved TableOrientedProgramming discussion below at PageAnchor Table-Oriented-Programming-Backing.

And it may be the case that certain tools are "good enough" in certain situations and easier to learn than some fancier thingy. If one says tool X is better for situation Y, they are obligated to make a case for that. "Trust me, I'm an expert" is not science.

In terms of programming tools, there are vanishingly few scientific studies that demonstrate one tool is better than another. We don't even agree on what "better" might mean; e.g., if it makes programming easier for the original programmer but harder for the maintenance programmer, is that "better" or "worse"? You could build a research career just trying to definitively answer that one question. Of course, you probably won't get funded for that research -- most funding agencies and companies don't care enough, relative to other priorities, to consider it worth bothering. So, most claims for tool 'x' are essentially a verbose way of saying, "I like 'x'", which is only a problem when I say "I like 'x' [because of my preferences, or reasons that matter to me]" and you respond with "Don't use 'x' [because of your preferences, or reasons that matter to you]". When that happens, there's a fight. Unfortunately, it's an un-resolvable fight, because the empirical bases (i.e., research) for resolution simply don't exist, and we'll probably never agree on the appropriate weight of the theoretical (e.g., simplicity, elegance, parsimony, safety, etc.) bases.
I disagree with that as the nature of the debate. Secondary evidence is being artificially elevated in importance, per below.
I suspect your detractors would disagree, and argue that theoretical evidence is being incorrectly deprecated in importance.
It is weak! --top
No, it isn't. Why do you think it is?
See below.

Now, back to your "torque angle gauge" analogy:

If you say tool X makes bolts less likely to fall off in the long term, then you should provide evidence for that. If you merely talk about the elegance of the physics behind a torque angle gauge, then you are not doing real science and one shouldn't just take your word for it. At least get simulations of vibrations that suggests it works better; an approximation of "actual testing", if you can't do actual field testing. "Bolts that were fastened with a torque angle gauge were 40% less likely to fall off than those fastened without them" is the kind of result we really want and one that customers and hobbyists alike can relate to. If you don't have such data, then IfYouWereSmartEnoughYoudJustKnow is a poor substitute and nobody should be lambasted for not accepting such at face value. Many of my detractors insist their alleged expert opinion is sufficient, not merely present it as a professional recommendation or anecdote.

Actually, I don't think any of your detractors have ever done that. Most have presented precisely the items of evidence that convinced them to use tool X in the first place -- and you categorically deprecate them. It appears that you only discuss tool X here once you've made up your mind about it, and once you've made your mind up about it, nothing will shift your view.

Sorry, they have not done so. You are mistaken. They are anti-empirical, insisting ArgumentByElegance or similar is plenty strong and sufficient. But if you view the debates different, then we'll just have to AgreeToDisagree. The GreatLispWar and thin-table debate comes to mind. I suppose some of the arguments are based on objective metrics such as parsimony (code size) and machine speed on a given platform, but WetWare should be heavily considered also, if not more so. Software is mostly for inter-human communication, not human-to-machine communication. Sometimes we view the purpose of software and its relationship to WetWare very differently. I believe my viewpoints on these to be based on rational assumptions which I do my best to describe and illustrate, but realize some disagree heavily. But it bothers me that they are so insistent they are right with no solid logic to back such alleged certainty. If you don't have solid evidence about what the goals of software "should" be, don't be so insistent you are correct.
No one here is anti-empirical. Most of us simply realise that there is virtually no empirical research to cite. In the absence of empirical data, it appears we consider theoretical qualities -- simplicity, elegance, parsimony, safety, etc. -- to have considerably more weight than you do.
I feel you exaggerate the strength of such evidence in the absence of empirical research. My detractors insist this kind of secondary evidence is strong. If it were merely given as a suggestion or personal recommendation, that's fine. In the absence of decent empirical evidence, ALL EVIDENCE given is WEAK and should be considered weak. -t
I feel you inappropriately deprecate the strength of such evidence in the absence of empirical research. Theoretical evidence, in some cases, is stronger than any other.
ArgumentByElegance is weak evidence.
ArgumentByElegance alone is weak evidence. Theoretical evidence is not limited to elegance. It includes simplicity, parsimony, safety, composability, expressiveness and extensibility, too.
If those hurt grokkability, they can be rendered moot features. For example, if heavy parsimony results in code a maintenance developer cannot read, then nothing gets done and the organization is outright stuck. Repetitious code, on the other hand, rarely gets an org outright stuck: it's just slow and labor intensive to change. I've talked to managers of many organizations, and non-grokkability generates far more horror stories than repetition. See StaffingEconomicsVersusTheoreticalElegance for more on this. -t
Grokkability is generally significantly more important than the others. And there are indeed many factors involved such that one has to weigh myriad trade-offs. Often one has to use professional judgment and professional judgement will differ. But some insist their judgement is superior, not respecting others' because they allegedly know more. Thus, they claim IfYouWereSmartEnoughYoudJustKnow. I have no problem with "professional judgement" that differs from mine, but I do have a problem with those who insist their professional judgement carries far more weight than others for wiki readers. It strongly appears their human ego is clouding their judgment about the strength of their anecdotal evidence. -t
Grokkability is subjective. You, your manager, and your colleagues are the only people who matter in deciding whether a feature is sufficiently grokkable or not. If it's not sufficiently grokkable, feel free to suggest ways to improve its grokkability. If you can't think of any and choose not to use that feature, that's fine. To the author of a feature, your personal ability to grok it or not is neither relevant nor of any concern, especially if others grok it.
Grokkability is potentially empirically testable, but we don't have such tests yet. And we can ignore it because it's hard to test, but then we are potentially committing the SovietShoeFactoryPrinciple sin. Most of those other aspects listed above don't have clear, objective tests either, so far. If we stuck with currently-measurable objective measurements, we'd be favoring the machine, and possibly using machine code. Are you truly suggesting that grokkability be ignored because it's difficult to measure?
No, I'm not suggesting it be ignored, and I would encourage you, your manager, and your colleagues to give it all appropriate attention. However, in discussions here about (say) higher level abstractions -- which may allegedly be less grokkable than (say) procedural programming a la ExBase in 1987 -- I don't think it warrants much consideration. It's up to you, as a feature user, to decide whether a feature is grokkable or not. It's not up to me, as a feature author or proponent, to be concerned about whether you may or may not grok the feature. At best, given a feature <X> and two implementations of it <A> and <B>, I'm only concerned which of <A> and <B> is easier to grok. I'm certainly not going to withdraw support for <X> -- or pepper my descriptions of it with caveats about how you or your shop should be extra careful -- because someone, somewhere, might not grok it. That's your problem, not mine.
I'm not understanding your point. Perhaps a code example might help. When you say, "feature user", do you mean like an API user, or an end user? Managers and owners typically have wanted me to code in a fashion that makes it relatively easy to get PlugCompatibleInterchangeableEngineers; and catering to a certain mid-level of abstraction seems to best fit that desire. In my experience talking with them, this desire for PlugCompatibleInterchangeableEngineers is often based on their past actual experience with maintenance staffing (aka "being burned") and NOT some random personal paranoia. Note we are wondering off-topic. Perhaps this section should be continued at and/or moved to StaffingEconomicsVersusTheoreticalElegance if you wish to reply. -t
When I say "feature user", I mean the programmer who uses a feature that I -- the feature author -- made available for use in a programming language, whether as a library routine or a syntactic construct. I have no problem with your managers and owners deprecating certain features; that's up to them. As a feature author, I don't care. There are other feature users, managers and owners who are happy to gain the advantage -- whatever it might be -- that my feature provides. I certainly care whether or not my feature is as grokkable as it can be for those who chose to use it, but I don't care if there are users, managers and owners who have no intention of using it no matter what I do to make it grokkable.

And the question about whether a hobbyist mechanic or a non-car mechanic should get the fanciest tightening tools possible is a question of weighing trade-offs: how much does it cost, how much is the training, how long does it take to learn it well enough, how much are the benefits compared to total costs, etc. Weighing these kinds of trade-offs is not an easy job and I do no trash other people for having different opinions and estimations on how to weigh such trade-offs, but I do complain about those who use ArgumentFromAuthority in a heavy-handed way, such as IfYouWereSmartEnoughYoudJustKnow intended as more than just personal anecdotes.

I don't think any of your detractors have ever done that, either.

That's not the way I see it. I see them very insistent based off of weak, if any, empirical evidence.
Actually, there simply isn't any empirical evidence. You appear to consider the lack of empirical evidence for 'x' to be a reason to reject 'x'. We consider theoretical evidence for 'x', even in the absence of empirical evidence, to be a reason to favour 'x'. This is especially true if we've tried 'x' and liked it. Liking 'x' serves as a form of personal empirical evidence, lending credence to our use of 'x'. Many debates seem to ensue when you take a glance at 'x' and don't like it. If there's no empirical evidence in favour of 'x', it appears our liking it and having theoretical evidence to support it is irrelevant, and you justify telling us we shouldn't use 'x' because it will be (you claim, anecdotally) more difficult for "the typical programmer."
No. As described above, it's my detractors' artificial elevation of the strength of second-rate evidence that is the real problem. I suppose I should document and mark where my detractors use statements like "obviously better" that are usually the trigger point for heavy debates. -t
No, as described above, it's your artificial deprecation of the strength of theoretical evidence that is the real problem. :-) "Obviously better" is sometimes really obviously better, purely on a theoretical basis.
As mentioned above, ArgumentByElegance is weak evidence.
As mentioned above, ArgumentByElegance alone is weak evidence. Theoretical evidence is not limited to elegance.
Yes, sometimes it's worse. And it's not a sufficient substitute for empirical testing.
Sometimes, what is worse?

Also, fastidious personalities and fastidious specialists tend to gravitate toward GoldPlating in many cases. I have a fastidious father, so I know first hand the kind of proportion-related mistakes such personalities make. -t

This insight into your personal psychology is revealing, even if it requires an unfortunate degree of Freudian-ism to appreciate it.

Note that your accusations that we are "fastidious" and "GoldPlating" could easily be thrown back at you as an accusation that you are careless and lazy, but I'm far too polite to do so.

I rank middle-of-the-road in terms of anal-retentive-versus-wild-cowboy design spectrum in terms of the personalities I encounter in the field. In general, I do believe that the heavily educated have a tendency toward GoldPlating. This is just a personal observation and I agree it may be seen as an AdHominem attack. But there may be certain personality factors that have a relationship to other personality factors, even though such "profiling" is often considered rude. For example, those in IT tend to have lower-than-average people skills, and I believe most would agree with that association.

Couldn't your perception that "the heavily educated have a tendency toward GoldPlating" be a demonstration of the BlubParadox?

The only time I've seen statements like this here was when someone was proposing known bad, failed models that could be easily found via google search by anybody who knew the correct terms for them, but the person proposing such things was using new terms for the same ideas. -- JoshuaHudson

If it's bad, point out why it's bad, such as showing how it prints out 2 + 2 = 5, and that should be the end of it. Something tells me there was some personal interpretation involved in that case rather than a clear and direct fault. -t

You just had to pick GreatLispWar as your only linked example, didn't you. Trying to argue that lisp isn't better is almost unwinnable due to BlubParadox alone.

Code has to be maintainable by blubs also. If you issue regular foot-soldiers nukes, bad things can happen. But if you have examples of CLEARLY "failed models", not just your personal opinion, feel free to list them.

I don't track who made which claims. Nevertheless:

SetTheBozoBitOnYourBoss?
- Not sure what this is in reference to. -t
CopyPasteProgramming?
- If copy and paste programming was a "failure", why is it still so common? I'm not necessarily condoning it here, just evaluating "clearly failed models" claims. And how you are measuring "fail" is in play. -t
ThreadMess
- I too am bothered by ThreadMess, but not sure how to fix it. A tool that's a better fit, such as a ParagraphWiki, perhaps could help factor out repetition. -t
Procedural over OOP for GUI programming
- I don't remember claiming that. Actually, a "GUI service" is the ideal model because one then is not hard-wiring the GUI engine to a specific programming language, which I believe has been a huge, standards-limiting mistake of current desktop-like GUI models. -t
  - I don't remember claiming that. [We can stop right here. Reading comprehension FAIL.]
  - Please do link/reference it if you honestly believe I claimed such. Otherwise it's anecdotal recall versus anecdotal recall. Or maybe I am misunderstanding context and you are claiming that procedural in general has failed at GUI's due to it's loss of market-share? I'd argue it's not if we look at the rise of the HtmlStack: it's mixed paradigm. But if we are not talking about claims made, then how does ArgumentFromPopularity[1] (GUI language usage) relate to the topic? Please advise.
Unbalanced scale of evidence where one side demands better evidence than that side offers
- Often the other side claims "clearly better" or similar. If you use phrases like "clearly X", then you have a higher obligation than somebody who believes their tool is "at least as good" or "not objectively worse" than the clearly-X-claimed-tool. -t

But I also know what the other side looks like:

HyperBooleanTuringMachineDraft (unable to finish due to not understanding the notation to write down the proofs required to collapse Godel -- but the halting problem is still dead)

Sorting between the two is hard, and until you show a tendency to clean old thread mess I will not contend with you.

PageAnchor Table-Oriented-Programming-Backing

I believe you are mistaken. I stopped insisting TOP was objectively better a good long time ago (when I realized everybody's WetWare is very different and that my own WetWare couldn't be used as a wide reference.)

I said "you've softened on that [TableOrientedProgramming was the best for every niche and domain usage] stance", and you appear to agree by saying "I stopped insisting TOP was objectively better a good long time ago." So what is it that I'm mistaken about?

You imply I swapped one "rant" for another, in a timed sense. That's simply not true.

Several times, you've explicitly drawn parallels between your former attacks on OO -- in which you offered TableOrientedProgramming as an alternative -- and your current depreciation of HigherOrderFunctions and the like. Therefore, it does appear that you've swapped one cause for another.

To make sure we are clear, I did not claim TOP was the only alternative to OOP. It's one of many (depending on specifics).

For a long time, it appeared that you felt TOP was the preferable alternative to everything.

Preferable? I don't think so. I often defend it as a viable/potential alternative to many design issues and still do. I do NOT insist it's objectively better, only that it deserves a fair consideration. If somebody finds clear and objective flaws (without counterpart/tradeoff flaws on the other side), then it may indeed deserve to be ignored. But, I have not seen that outside of machine performance issues for "small" hardware.

I'm not sure I'm interpreting the rest of the sentence correctly. Please elaborate on "drawn parallels", and explain its relationship with TOP. (Why are both mentioned in the same sentence?) I did mention there are similarities to my debates with OO-heavy-proponents and the HOF debates in terms of the kind of evidence and accusations that got tossed around. But what this has to do with TOP, I don't know. (OO-heavy-proponents suggested that if one simply use it long enough, it will eventually click and one will then "just know" that OO-everywhere is better.)

I'm noting the similarity between your former anti-OOP (aka pro-TOP) stance and your current anti-HOF stance.

Sorry, I don't see a connection. And as already explained, I never pitted it as OOP-versus-TOP directly such that it was NOT OOP-versus-TOP. TOP is one of multiple alternatives to OOP (although specific domains may limit the choices).

Got here from another case completely outside of the debates at c2. Had to deal with vendor SequelMed? that could not understand the consequence of the fact that in a message, ack protocol that "sent ack" != "received ack", and failed to implement elimination of duplicate messages, nor make message processing idempotent. Customer complained about duplicate charges. Obviously, customer cannot be expected to understand this, but the vendor ought to have. The engineer already had all the facts, but could not do the induction. The phrase "no ack for ack" was telling. -- JoshuaHudson

Perhaps you just didn't explain it well enough, such as an analogy of people passing notes through slots in huts and how somebody ends up with duplicate coconuts. I've had issues that at first seemed too confusing to the customer, but I later found out how to explain it better. Sometimes time is scarce such that better explaining cannot be done in the time allowed. That's a tricky problem, but this topic is not really about time management and as a working assumption I shall assume the "customer" has sufficient time to receive explanations and ask questions.

And even if they don't understand something, empirical numeric metrics can still be used, such as testing that "protocol X results in 10x fewer duplicates than protocol Y". It's clear the frequency of duplicates, something quantifiable, mattered to this customer. Thus, claims about which technique results in fewer duplicates can be empirically tested. In practice, every part may not be able to be subject to testing, but that's more of a resource constraint issue and this topic is not about making decisions in a rush or on the cheap. (Trust sometimes has to be a shortcut to empirical testing in practice.)

Unfortunately we got here because OV didn't understand idempotence and implemented broken X' instead or there would have been no observed duplicates.

In theory, even if the OV remained ignorant, tests or scenarios could have been devised to demonstrate that his/her version of messaging coordination was inferior to the "correct" way, resulting in an integer count of duplicates to compare both techniques side-by-side. OV couldn't argue with "47 dups > 0 dups". Typically the owner of the tool (application) would make the final choice, not an implementation partner.

You underestimate the magnitude of OV's error. They claimed we should have built our side to send them each message once, but sending it again if they did not process it.

Without the details of the squabble, I cannot really comment. I don't know the circumstances of the problem. Duplicates can be empirically tested; that's all that matters from the perspective of this topic.

http://en.wikipedia.org/wiki/Two_Generals%27_Problem

I guess I wasn't clear. I meant the nature of the argument between you and the "problem person". He or she may be doing the equivalent of a copy-machine technician arguing with a rocket scientist at NASA about which rocket engine type is better. They would be arguing the engineering side of things, not the "results" side of things. A rocket "customer" cares about accuracy, safety, cost, speed, setup time, etc. of the vehicle (rocket). Each of these can be empirically numerically measured in various ways. Arguing beyond such "consumer metrics" appears to be the problem in your case. If he or she insists that protocol B produces fewer duplicates than protocol A, then he/she is obligated to empirically demonstrate that with tests or scenarios.

The nature was that he was claiming to the customer that we should have implemented our side of the protocol in such a way that we could prove was mathematically impossible and that we were responsible for the duplicates because of that. While we could have built a receiver that would have shown no duplicates, that would not placate the customer.

That what was "mathematically impossible"? Perhaps you could have created some cards or paper plates with letters on them or something and string to represent boundaries, and sit down with him to demonstrate and go over your understanding of the issue. If he says, "I don't have time for that", then reply that you are not understanding his point of view and a sit-down meeting is the only way you can think of to clarify the issue. The ball is then back in his court: his time investment choice falls on him.

{Many years ago, my software company helped sponsor the local soccer club and donated software development time. My business partner developed an application to manage scheduling of matches on the various soccer fields. To keep things fair, the club wanted every team to play an equal number of games on every field. Unfortunately, there were an odd number of teams and an even number of fields, so some teams would inevitably wind up playing more or less games on field 'x' than another team. This, according to the club president, was unacceptable. Commissioning another field or closing one was also unacceptable, as was removing or adding a team. So, my business partner requested time to do a presentation to explain the problem to the president and his board.}

{My partner's request was granted, and he did a brilliant presentation with illustrations, props, and clever explanations that proved -- beyond a shadow of a doubt, and in ways that a child could understand -- that an odd number of teams and an even number of fields would always result in some teams playing more games on field 'x' than others. To do otherwise was mathematically impossible. The board thanked my partner and excused him from the room to deliberate on what should be done.}

{After a half hour or so, they called him back in. Their solution was simple: The same number of teams would be retained. The same number of fields would be used. However, the soccer club could now proudly guarantee that every team would play the same number of games on every field. How did they do it? They made it a policy that every team play the same number of games on every field. Problem solved!}

{Not surprisingly, my partner quit the soccer club. Related: }

Some people just like being dicks for the pleasure of being dicks. If the soccer dude claims it is mathematically possible, then he/she is obligated to provide a mathematical proof, even if it requires hiring a mathematician. This problem appears to be something that can be proven mathematically either way and doesn't depend on fuzzy WetWare claims, etc.

However, if it was a corporation and I was a consultant, I'd consider pulling the plug, saying something like, "I guess I am not smart enough to solve this problem to your satisfaction, and perhaps it's time for you to try another contractor. If the new contractor solves the problem, I'll buy both of you a lunch. Nice working with you." Sometimes owners just want to force people out they don't personally like and rotate in contractors or employees until they find one they do like. The technical side of things is secondary and is used as a facade for social goals.

Related: JustMakeItRight.

{I don't think the soccer club board was that devious. They were mathematically ignorant, and genuinely believed mathematical truth could be overridden by legislation. Of course, that only demonstrated the degree to which they understood neither. It's not the first time that's happened: http://en.wikipedia.org/wiki/Indiana_Pi_Bill }

I truly doubt they believed that. There was likely a political motivation behind it, even if it was veiled in pseudo-science. Politics is an ugly game of perception, manipulation, and public opinion.

Go the the town hall and bet Mr. Soccer real money (5 grand?) if they can prove such combinations are mathematically possible. If it comes to real money and embarrassment and P/R of losing, the logical side of their brain may tell the bullshitting side to shut up for a while. Often it's just the case that there's no real penalty for being cocky or stupid.

{I met some of them. They truly believed it. Never underestimate the power of limited schooling and feeble intellect to sustain a belief that mathematics is subject to human whim. To the uneducated, it's a product of human invention, as subject to re-engineering as any gadget.}

Bet them money, have them sign it, and get rich. And arrogance and education are orthogonal. There have been a good many highly educated people who's ego or stubbornness made them stubbornly stick to faulty or evidence-poor positions. Human nature makes HumansSuck, not education. But, it's still usually better to work with well-educated ego-infected nuts than poorly educated ego-infected nuts. But it's usually easier to discredit the stupid ones because the smart ones know enough to make tougher-to-crack bullshit because they can sprinkle it with actual partial truths or close-enough buzzwords.

Footnotes

[1] ArgumentFromPopularity could be considered a rough approximation of or a proxy of WetWare fit, but also band-wagon hopping (fad chasing) plays a big role in my opinion. People often chase the latest fads out of fear of being left behind with unmarketable/obsolete skills, regardless of the merit of the fads. If enough hype is built up around a technology or tool, then it generates a kind of self-reinforcing network-effect. -t

CategoryEvidence CategoryMetaDiscussion