[Haskell-cafe] the problem of design by negation

Michael Mossey mpm at alumni.caltech.edu
Fri May 22 03:35:34 EDT 2009

Conal Elliott wrote:
> Hi Michael,
> I'm going to hazard a guess.  Please let me know how accurate it is.


I think you described this situation well. You must know this kind of
person---I'm sure there's more than one in the world!

> 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.

Yes, that's the impression I get from this guy. His personality causes him
to derive absolute rules or blanket statements from experience, instead of
a more gentle kind of wisdom. The more experience he gets, the more he's
full of constraining rules. So I really did mean to say that his design is
the ONLY thing possible after eliminating everything that won't fit with
his rules.

> 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.

You got it---the guy is great at winning debates because he is very
confident and can so quickly poke holes (what *seem* to be holes) in any
other position. Moreover, his confidence is why he is lead software
architect... managers are impressed by alpha males and tend to be alpha
males themselves.

> 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

Good quotes. I was trying to get across this idea of imagination,
creativity, finding solutions in unlikely places.

Here's another one:

"The whole trouble with the world is that fools and fanatics are always so
certain of themselves, and wiser people, always so full of doubts."
- Bertrand Russell

> <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>

That's good advice. I'm not sure how well this situation can work because
I'm one of these people who is "full of doubts," which I regard as
ultimately a positive trait, but it makes me poor at debate. (I know you
are not suggesting I "debate" him, but he wants to turn everything into a
debate, and it takes a very level-headed outgoing person to keep up with him.)

The best result from this experience is that I can improve my *own* design 
process. For example, I'm working on a personal project related to music, 
and after a few weeks of design, I realized that my thinking had turned 
into design by negation. I felt unhappy with every choice, and started to 
think of the design as the unhappy, but least unhappy, compromise. This is 
probably an old habit of mine. So I want to shift my thinking, by listing 
goals for the design, and finding ways to meet all of them. Win-win instead 
of lose-lose.

Based on a previous reply, I think some people think this sounds like vapid 
cheerleading, but I think you would agree with me that life (and software) 
always offers more possibilities when we engage our imagination with hope 
and energy, not giving up too soon, being willing to sit with problems for 
a time without a definite conclusion.


More information about the Haskell-Cafe mailing list