Re: [Haskell-cafe] the problem of design by negation
On Thu, May 28, 2009 at 5:59 AM, Conal Elliott co...@conal.net 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the problem of design by negation
What I do like about this so-called negative approach is that it represents a part of a program's documentation that is usually omitted. You can look at the code and see exactly how and (to a certain extent) why the program does what it does, but what you can't see is all the things it doesn't do, and the reasons it doesn't do them. This can be extremely important to know when you are thinking about modifying a program. The change you are considering may have already been tried and rejected, but unless these sorts of negative decisions are documented in the software you may end up spinning your wheels. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the problem of design by negation
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. On Wed, May 27, 2009 at 8:34 PM, David Fox dds...@gmail.com wrote: What I do like about this so-called negative approach is that it represents a part of a program's documentation that is usually omitted. You can look at the code and see exactly how and (to a certain extent) why the program does what it does, but what you can't see is all the things it doesn't do, and the reasons it doesn't do them. This can be extremely important to know when you are thinking about modifying a program. The change you are considering may have already been tried and rejected, but unless these sorts of negative decisions are documented in the software you may end up spinning your wheels. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the problem of design by negation
On Tue, 26 May 2009, Richard O'Keefe wrote: 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'. Along similar lines, Esther Dyson's .sig says Always make new mistakes! Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the problem of design by negation
G'day all. Quoting Conal Elliott co...@conal.net: 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 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. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the problem of design by negation
On 26 May 2009, at 12:54 pm, a...@spamcop.net 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'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the problem of design by negation
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the problem of design by negation
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
Re: [Haskell-cafe] the problem of design by negation
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 m...@alumni.caltech.eduwrote: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the problem of design by negation
On Thu, May 21, 2009 at 10:53 PM, Conal Elliott co...@conal.net 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the problem of design by negation
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 co...@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 m...@alumni.caltech.eduwrote: 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
Re: [Haskell-cafe] the problem of design by negation
Instead of continuing to make the request, ask what it would take for the request to be possible. Thanks, Jason. I like this shift. It moves the dynamic away from a tightly confined yes/no (and often win/lose) to an expansive *how*. It welcomes collaboration in finding something better than either yes or no to the original request, in that both/all parties' needs can be addressed, not just one. - Conal On Thu, May 21, 2009 at 11:04 PM, Jason Dagit da...@codersbase.com wrote: On Thu, May 21, 2009 at 10:53 PM, Conal Elliott co...@conal.net 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the problem of design by negation
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
Re: [Haskell-cafe] the problem of design by negation
On Thu, May 21, 2009 at 00:54, Michael Mossey m...@alumni.caltech.edu wrote: 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 think there is often a good default solution which is so obvious that experienced software architects won't even bother to mention. This is the case for both examples that you mention (unique keys in a database, garbage collection). They then go on to give reasons why the default solution would not work in their case. Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the problem of design by negation
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 m...@alumni.caltech.eduwrote: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] the problem of design by negation
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
Re: [Haskell-cafe] the problem of design by negation
On Wed, May 20, 2009 at 3:54 PM, Michael Mossey m...@alumni.caltech.edu wrote: 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. Design by Thomas the Tank Engine? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the problem of design by negation
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. Design is always constrained, and arguably every choice that is made should be justified, that includes explaining why a particular solution was discarded. I can understand your frustration with the negative attitude, I'm just trying to say that I've most often been in the opposite position; no one can answer why several, often much simpler, designs weren't good enough. Often there is not even any record of any decisions having been made at all, which to me suggests that no one really thought about the problem at all before implementing a solution. In short, I wouldn't mind seeing a bit more negative attitude in the place where I work :-) /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
