[Haskell-cafe] the problem of design by negation

[Conal Elliott]

>
> One flimsy argument I often hear is "It wouldn't work because how ...", or
> "because what ...".  As if a question were an argument. I call this rather
> popular tactic "proof by ignorance" or "proof by lack of imagination".
> [...]


I just remembered another popular variation on this bogus "argument". If you
question someone's claim of impossibility (or "the only possibility"), they
may retort: "Well, then how would you do it?"  The Game here is that if you
don't have an answer, the other guy is right!  I don't know why people
perpetrate and fall for this game.  One response I like is to affirm the
question.  "Yeah, how indeed!  Anyone have some creative ideas?  Who wants
to brainstorm?"  I gather that some people are terribly uncomfortable
without certainty.  If you take away their certainty, they demand an
immediate replacement!  These folks will suck the creativity out of a room
if they can, because creativity requires curiosity, and curiosity requires
willingness not to know.

  - Conal

On Thu, May 21, 2009 at 10:53 PM, Conal Elliott <conal at conal.net> wrote:

> Hi Michael,
>
> I'm going to hazard a guess.  Please let me know how accurate it is.
>
> When asked to justify his design, the lead software architect explains
>> everything that *wouldn't* work. "We couldn't have a unique key for every
>> entry because blah blah blah. We couldn't use a garbage collector because
>> blah blah. We couldn't write a sugar layer because then you have to document
>> it separately blah blah." So the chosen design seems to be the only thing
>> left after eliminating everything you can't do.
>>
>
> My guess is that your software architect is making flimsy arguments.  It's
> usually very difficult to prove that something *wouldn't* work.  In my
> experience, people make blanket statements about what cannot work, when the
> truth is that they just don't know how and don't have the imagination or
> will even to entertain the possibility of ways that they can't yet see.
> Instead of using logic and evidence, these people bolster their claims
> (often mistakenly called "arguments") by putting across confident language
> ("obviously", "clearly", "without a doubt"), body posture, facial
> expression, and voice tone.  When someone is on solid ground, these bravado
> tactics are unnecessary.  (I think of "obviously", etc as words that are
> useful only when inaccurate.  See
> http://conal.net/blog/posts/fostering-creativity-by-relinquishing-the-obvious/.)
>
> One flimsy argument I often hear is "It wouldn't work because how ...", or
> "because what ...".  As if a question were an argument.  I call this rather
> popular tactic "proof by ignorance" or "proof by lack of imagination". I
> don't know where people get the idea that this sort of thing is rational.
> If I'm ever tempted to give it any weight, I think of Arthur Hoppe's proof
> of the existence of God: "If there's no God, then who pops up the next
> kleenex?"
>
> Some of my favorite quotes on this dynamic:
>
>     "Doubt is not a pleasant condition, but certainty is absurd." -
> Voltaire
>
>     "They are ill discoverers that think there is no land, when they can
> see nothing but sea." - Francis Bacon
>
>     "To be positive: To be mistaken at the top of one's voice." Ambrose
> Bierce
>
>     "The greatest obstacle to discovering the shape of the earth, the
> continents, and the oceans was not ignorance but the illusion of knowledge."
> - Daniel J. Boorstin
>
> <advice>
> One thing you may try is to ask the architect for evidence and/or logical
> proof of his claims that something cannot work.  As much as you can, ask
> from a place of curiosity and even awe.  After all, existence can often be
> proved by demonstrating an example, while non-existence proofs tend to be
> much more profound.  And stick to your open-minded disbelief until you
> really see evidence or logical rigor.  If the architect gets flustered and
> embarrassed, he may well go on the attack.  After all, bravado signals weak
> ego, which can quickly become a cornered animal.  So pay attention to his
> stress level, and help his salvage his ego, by suggesting he let you know
> more about the evidence and/or logic when he's worked it out.  Be careful to
> stay in your integrity, neither going along with someone's forcefulness, nor
> representing yourself as having more grounds for confidence than you really
> do.
> </advice>
>
> Whether or not my guess is accurate or my advice relevant, good luck!  I'd
> love to hear how this situation develops.
>
>    - Conal
>
>
>
> On Wed, May 20, 2009 at 3:54 PM, Michael Mossey <mpm at alumni.caltech.edu>wrote:
>
>> This is not directly related to Haskell, but it's a thought that occurred
>> to me after exposure to the Haskell community.
>>
>> I've spent most of the past 15 years doing scientific programming. The
>> lead software architect and software managers are using good software
>> engineering practice, though (this is *scientific* programming, not
>> *programming by scientists*, ha ha). But, there is a particular culture in
>> my company that has become more obvious to me by contrast to the Haskell
>> community.
>>
>> I call it "design by negation." When asked to justify his design, the lead
>> software architect explains everything that *wouldn't* work. "We couldn't
>> have a unique key for every entry because blah blah blah. We couldn't use a
>> garbage collector because blah blah. We couldn't write a sugar layer because
>> then you have to document it separately blah blah." So the chosen design
>> seems to be the only thing left after eliminating everything you can't do.
>>
>> I want to aspire to "positive design." I want to list the goals, and think
>> of design as making clever choices that meet all the goals.
>>
>> I don't mean to suggest that design is never constrained. It often is. But
>> it's a mindset I'm talking about. I don't like this mindset of design by
>> negation.
>>
>> -Mike
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090522/0937d42e/attachment.html