On Thu, May 21, 2009 at 10:53 PM, Conal Elliott wrote:

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

Thanks Conal for that sagely advice. I recently asked my local conversation expert how to deal with passive aggressive people/managers, and he gave similar advice. He said that when someone is dragging their feet or providing excuses, change the conversation into one about problem solving. Instead of continuing to make the request, ask what it would take for the request to be possible. I think your advice is exactly that, just in a slightly different context. Also, in the times when the speaker understands the problem better than myself, I tend to learn something new about the problem domain that, whether it is a show stopper or not, is a significant issue to address. Thanks, Jason

Design-by-negativity can *be* a way of being creative. I've lost count of the number of times that I've been explaining to someone why something can't be done, and suddenly realised that one of the reasons was invalid and seen how to do it. The key is not whether you explore the design space from a positive end or from a negative end, but whether you *explore* it.

The main objection I have to the negative process (can't be done) is that is so often bogus. "Proof by lack of imagination". I guess it works for Richard, though not for Michael's architect, because Richard is able to catch his bogus reasoning *and he is willing*** to do so, which requires humility and ego-strength. - Conal On Sun, May 24, 2009 at 6:35 PM, Michael P Mossey wrote:

Richard O'Keefe wrote:

...

Design-by-negativity can *be* a way of being creative. I've lost count of the number of times that I've been explaining to someone why something can't be done, and suddenly realised that one of the reasons was invalid and seen how to do it.

The key is not whether you explore the design space from a positive end or from a negative end, but whether you *explore* it.

Hi Richard,

I think we using "positive" and "negative" in a bit of a different sense (which may be my fault for not explaining perfectly in the first post). There are both positive and negative *facts* about design. There are things you can do, and things you can't. These are facts. I'm referring more to a specific kind of process (a specific kind of exploration)---in my terms, "design by negation" means that you dominant activity in design in cutting away possibilities, and what's left (however awkward) is what you must build. I have done this by habit, but I would like to shift into a mode of design that is focused on construction rather than destruction---to view design as an opportunity to meet most goals by clever combining of facets.

Thanks,

Mike _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 26 May 2009, at 12:54 pm, wrote:

Conal is definitely on to something here. I've noticed that the best designers have this weird personality quirk that allows them to put all of their effort into pushing an idea, and then instantly back down and revise the moment that it's been shown that the idea won't work.

I have one of Brian Marick's (www.exampler.com) stickers on my door. It reads to be less wrong than yesterday Two quotes I often give my students: Brethren, I beseech you in the bowels of Christ, consider it _possible_ that you _may_ be wrong. Oliver Cromwell Fear most of all to _remain_ in error. Me, deliberately misquoting Kierkegaard, quoting Socrates. I changed 'be' to 'remain'.

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

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 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Conal Elliott wrote:

Hi Michael,

I'm going to hazard a guess. Please let me know how accurate it is.

Conal, 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. Thanks, Mike

On Thu, May 28, 2009 at 5:59 AM, Conal Elliott wrote:

Thanks for bringing in this angle, David.

My preference is for honest and humble practice and documentation of negative design.  Instead of saying that something "won't work", "can't work", "is impossible" etc (or rephrased via "must", "only", etc), I'd like honest admissions like "I couldn't figure out X", "I got stuck on Y", etc. After all, someone else might get further.  Or, in the rare cases, when something actually is impossible, say so prove it.

Yes, this angle is important, escpecially if you like me read a lot of code and end up thinking "why is this code so complicated, there must be an easier way". I often feel that thinking like that prevents quick understanding of the code, simply because my brain is pre-occupied with solving the problem more elegantly while trying to understand what is going on :-) Often a particular solution isn't impossible to use (i.e. the words "can't", "won't" etc shouldn't be used), instead solutions aren't as good as others when resource constraints into account. Of course the "negative reasons" must be backed up with data (sometimes rough estimates are enough), but this brings me to other pet peeves of mine at work, the general lack of non-functional requirements and prototyping with performance tests. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe