[Haskell-cafe] the problem of design by negation

[Conal Elliott]

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/90050904/attachment-0001.html