You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Pete Carapetyan <pe...@datafundamentals.com> on 2002/06/27 01:59:36 UTC
AntiPattern Genius
This antipattern thing which Berin brought up has the capability of
turning Avalon into a totally intuitive, understandable phenomenon, even
the same Avalon that was not understable before. Only by changing how
you describe it - starting with antipatterns.. Make it simple without
having to change anything !
Here is why.
Everybody understands anti-patterns. Few understand patterns, or even
care to, without a big anti-pattern staring them in the face. Chuck you
farley, I ain't studying no patterns.
Ask people what they want, they will say they don't know. But give them
something - anything - and they will read you the riot act for 20
minutes about how that wasn't what they wanted, and why couldn't you
have figured that out?. People react to what they see is wrong. That is
why I am here. I have lived the big ball of mud so long I don't like it
any more. On the other hand, no big ball of mud, no reason for Avalon,
unless you are also some kind of re-use freak or something, and even
then it takes a while to get why OO isn't the answer for all situations.
But there is something even better about this anti-pattern approach !
The BEST thing about the anti-pattern approach is it allows for *Walking
The Tree Of Increasing Complexity* as a mode of learning Avalon
techniques and syntactical approaches. The importance of the tree of
complexity can not be overstated. This is what makes Avalon
understandable and intuitive where it was previously neither. As follows:
AVALON INSTRUCTIONS MANUAL:
-------------------------------
Here is the simplest most straightforward use of Avalon. Exhibit A. Easy
for anyone to understand. Applicable in many instances such as blah or
blah. Simple COP. Addresses the anti-pattern of no re-use, and in
addition the anti-pattern of big ball of mud. Not much to it. Feast and
enjoy.
But wait ! When you have a level nnn anti pattern such as blah, you use
this next more complicated version of Avalon's pattern, Exhibit B. You
would use this in cases such as blah or blah or blah, for example. Don't
worry about it unless you need it though.
Next, imagine you have a level nnnn anti pattern such as blahHeh. Now
that can be a little trickier. In this case, you use an even more
complicated version of Avalon designed for this anti pattern. Exhibit C.
A little bit of thought involved , because you have to do xxx and yyyy
to make it work, and it can blow up on you if you don't watch for zzzzz.
But it works in the case of, for example blah or blah or blah.
etc. etc etc - all the way up the tree of complexity - from easiest to
hardest.
Got a project? Want to use Avalon? Take all your pieces, do a quick scan
on the examples to see which of your components are similar to which
examples and thus will have to use which level of complexity. You can
gauge your approach in a manner that allows you to build your skill set
and your time budget and your own tree of knowledge by starting with the
simple components first, and gradually migrating to the most complex. Oh
that one? That's a level nnnn, better learn that after this one. Heh
cool, found this one already done. Good, it's only a level nnnn. I think
I'll use that just like it is. And on an on.
Now this is a very intuitive way to learn about the nuances of COP, and
it is a tree of increasing complexity which you don't even really need
to learn unless you have the applicable situation. A situation, which,
by the way can be comparatively easy to spell out for you in plain
English - as a description of similar situations.
You could even have a cute section challenging people to see the
anti-pattern in this story, kind of like finding the hidden shoe in this
figure. A marketing person's dream.
Now consider how we are doing it now.
1. Antipatterns are known only by committers - or at least for the most
part.
2. We preach at potential users from up on high - you *should* do this
because we know better.
3. Solutions are 12 levels of iteration deep - each iteration addressing
an anti-pattern identified (and probably forgotten by some).
4. *What's in it for me?* is not even brought up - it is just assumed
that you know about the antipatterns.
5. DENIAL is the pattern that prevents someone from accepting Avalon
into their life.
6-infinity. Plenty more of similar to 1-5 above. Talking about a set of
marketing anti-patterns !
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AntiPattern Genius
Posted by Leo Simons <le...@apache.org>.
On Thu, 2002-06-27 at 01:59, Pete Carapetyan wrote:
> This antipattern thing which Berin brought up has the capability of
> turning Avalon into a totally intuitive, understandable phenomenon, even
> the same Avalon that was not understable before. Only by changing how
> you describe it - starting with antipatterns.. Make it simple without
> having to change anything !
yup. With the footnote that at the should-be-understandable-for-all-
docs, I feel we should not talk about patterns, antipatterns etc etc,
but just show examples of how to use the interface. There's people that
won't care about the why and just want to know the how.
> AVALON INSTRUCTIONS MANUAL:
> -------------------------------
<snip>
this is cool. If you could turn it into xdocs, blah blah blah, that'd be
even better!
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AntiPattern Genius
Posted by Corey Jewett <co...@triumphevents.com>.
Me. I'd never even heard of anti-patterns until sometime in the last 2
weeks. I did have some familiarity with rudimentary patterns (singleton,
flyweight, etc.)
Don't know if that's typical or not. I'm betting it's more common than
you think and less so than I do.
I think Paulo's approach of show them the greatness and if they don't
get it or want more examples of why it's great then give them
anti-patterns. If they see the greatness and want to use it then take
them straight into using Avalon, coming back to anti-patterns when you
talk about component design.
Corey
On Thu, 2002-06-27 at 20:43, Pete Carapetyan wrote:
> Paulo Gaspar wrote:
>
> >I follow the Anti-Pattern thing since 4 years ago. I like it. It
> >is a great argument.
> >
> >What I disagree is about making the central/introductory argument
> >for Avalon.
> >
> >First show how it is great, THEN show how it avoids bad things.
> >
> Makes the assumption that the person being showed has the same sense of
> what is great that you or I do.
>
> My sense of the market is that without anti-patterns, the great features
> of Avalon resonate like a good yawn to the typical developer. But I'd be
> happy to be proven wrong. Can you offer any observations that show
> developers who even give Avalon a second click, without a sense of the
> anti-patterns already deep in their bones?
>
> The best use of an anti-pattern as a communication device that I have
> seen is a crack that my nephew was walking around with a couple years ago.
>
> *New breakthroughs in toilet paper technology.*
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AntiPattern Genius
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Paulo Gaspar wrote:
>I follow the Anti-Pattern thing since 4 years ago. I like it. It
>is a great argument.
>
>What I disagree is about making the central/introductory argument
>for Avalon.
>
>First show how it is great, THEN show how it avoids bad things.
>
Makes the assumption that the person being showed has the same sense of
what is great that you or I do.
My sense of the market is that without anti-patterns, the great features
of Avalon resonate like a good yawn to the typical developer. But I'd be
happy to be proven wrong. Can you offer any observations that show
developers who even give Avalon a second click, without a sense of the
anti-patterns already deep in their bones?
The best use of an anti-pattern as a communication device that I have
seen is a crack that my nephew was walking around with a couple years ago.
*New breakthroughs in toilet paper technology.*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AntiPattern Genius
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
>
>
>>>First show how it is great, THEN show how it avoids bad things.
>>>
>>>
>>:) How do you propose to show it is great without showing how
>>to avoid bad things?
>>
>>
>simple enough. Show current well-designed piece of OOP software. Then
>show how refactoring it to be avalonized is easy and has many
>advantages.
>
>
Puh-leeeez.
No offense but I think you guys give people too much credit. I see
dozens of cool ideas a day. Most get dismissed before the second click.
What makes other developers different?
You need to be at least *mildly* realistic.
RE: AntiPattern Genius
Posted by Leo Simons <le...@apache.org>.
> > > :) How do you propose to show it is great without showing how to
> > > avoid bad things?
> >
> > simple enough. Show current well-designed piece of OOP
> > software. Then show how refactoring it to be avalonized is
> > easy and has many advantages.
>
> Ho hum.
>
> It's just not compelling enough. :)
that's just because I didn't spell out the advantages. Surely, you know
them already =)
- LSD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AntiPattern Genius
Posted by Stephen McConnell <mc...@osm.net>.
Paulo Gaspar wrote:
>You do NOT say that the Brabant (a car brand that was very used
>in the old East Germany) "he" invented is a piece of crap. What
>you do is showing "him" the BMW you built. Than you explain all
>the nice features and smart design and get "him" to admire how
>good the whole think looks.
>
>When he is already sold, seduced by the most obvious positive
>aspects, then you tell "him" some details of how you avoided
>some common design problems/glitches (the anti-patterns). But
>at this time it already sounds like you are already telling
>"him" how smart you really were and not how stupid "he" was.
>
>Most people will only understand that their way is bad after
>you show them a much better way.
>
>You have to show the better way BEFORE you point that they're
>way is wrong, or you will loose the audience before you finish
>telling them what you have to say.
>
>
+1^102463521897
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AntiPattern Genius
Posted by Paulo Gaspar <pa...@krankikom.de>.
You can also show some samples of the container implementations
with cases that get specially easy to code, before going to the
anti-pattern thing,
Many products have this kind of think on their promotion
material because it works. It works because programmers (unlike
mathematicians) learn better by example.
Examples are also a good starting point to talk about the
anti-patterns that were avoided.
This is a much smoother introduction than saying "all you are
doing is wrong".
You do NOT say that the Brabant (a car brand that was very used
in the old East Germany) "he" invented is a piece of crap. What
you do is showing "him" the BMW you built. Than you explain all
the nice features and smart design and get "him" to admire how
good the whole think looks.
When he is already sold, seduced by the most obvious positive
aspects, then you tell "him" some details of how you avoided
some common design problems/glitches (the anti-patterns). But
at this time it already sounds like you are already telling
"him" how smart you really were and not how stupid "he" was.
Most people will only understand that their way is bad after
you show them a much better way.
You have to show the better way BEFORE you point that they're
way is wrong, or you will loose the audience before you finish
telling them what you have to say.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, June 27, 2002 3:56 PM
> To: 'Avalon Developers List'
> Subject: RE: AntiPattern Genius
>
>
> > From: Leo Simons [mailto:leosimons@apache.org]
> >
> > And this to start your documentation with?
> >
> > I agree it is very good to have such docs, argument is just
> > that it shouldn't be the primary bit.
>
> You start out with a little primer on COP, introducing the
> terminology and concepts. If they can see added benefit at
> this stage then great, many people require a bit more.
>
> Then you go into how Avalon helps you avoid common programming
> traps. At this point if you haven't won them, then they are
> in willful denial.
>
> "There is none so blind as the one who WILL not see"
> - Can't think of the guy's name...
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AntiPattern Genius
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> And this to start your documentation with?
>
> I agree it is very good to have such docs, argument is just
> that it shouldn't be the primary bit.
You start out with a little primer on COP, introducing the
terminology and concepts. If they can see added benefit at
this stage then great, many people require a bit more.
Then you go into how Avalon helps you avoid common programming
traps. At this point if you haven't won them, then they are
in willful denial.
"There is none so blind as the one who WILL not see"
- Can't think of the guy's name...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AntiPattern Genius
Posted by Leo Simons <le...@apache.org>.
And this to start your documentation with?
I agree it is very good to have such docs, argument is just that it
shouldn't be the primary bit.
- LSD
On Thu, 2002-06-27 at 15:41, Leo Sutic wrote:
> I agree with Berin.
>
> A simple:
>
> This is how Avalon solves common problems:
>
> Problem: <antipattern 1>
> Example: <example of antipattern 1>
> Solution: <solution 1>
> <solution 1, concrete>
>
> Problem: <antipattern 2>
> Example: <example of antipattern 2>
> Solution: <solution 2>
> <solution 2, concrete>
>
> Problem: <antipattern 3>
> Example: <example of antipattern 3>
> Solution: <solution 3, abstract>
> <solution 3, concrete>
>
> .
> .
> .
>
> /LS
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: den 27 juni 2002 15:35
> > To: 'Avalon Developers List'
> > Subject: RE: AntiPattern Genius
> >
> >
> > > From: Leo Simons [mailto:leosimons@apache.org]
> > >
> > > > > Berin,
> > > > >
> > > > >
> > > > > I follow the Anti-Pattern thing since 4 years ago. I
> > like it. It
> > > > > is a great argument.
> > > > >
> > > > > What I disagree is about making the
> > central/introductory argument
> > > > > for Avalon.
> > > > >
> > > > > First show how it is great, THEN show how it avoids bad things.
> > > >
> > > >
> > > > :) How do you propose to show it is great without showing how to
> > > > avoid bad things?
> > >
> > > simple enough. Show current well-designed piece of OOP
> > > software. Then show how refactoring it to be avalonized is
> > > easy and has many advantages.
> >
> > Ho hum.
> >
> > It's just not compelling enough. :)
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AntiPattern Genius
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
I agree with Berin.
A simple:
This is how Avalon solves common problems:
Problem: <antipattern 1>
Example: <example of antipattern 1>
Solution: <solution 1>
<solution 1, concrete>
Problem: <antipattern 2>
Example: <example of antipattern 2>
Solution: <solution 2>
<solution 2, concrete>
Problem: <antipattern 3>
Example: <example of antipattern 3>
Solution: <solution 3, abstract>
<solution 3, concrete>
.
.
.
/LS
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: den 27 juni 2002 15:35
> To: 'Avalon Developers List'
> Subject: RE: AntiPattern Genius
>
>
> > From: Leo Simons [mailto:leosimons@apache.org]
> >
> > > > Berin,
> > > >
> > > >
> > > > I follow the Anti-Pattern thing since 4 years ago. I
> like it. It
> > > > is a great argument.
> > > >
> > > > What I disagree is about making the
> central/introductory argument
> > > > for Avalon.
> > > >
> > > > First show how it is great, THEN show how it avoids bad things.
> > >
> > >
> > > :) How do you propose to show it is great without showing how to
> > > avoid bad things?
> >
> > simple enough. Show current well-designed piece of OOP
> > software. Then show how refactoring it to be avalonized is
> > easy and has many advantages.
>
> Ho hum.
>
> It's just not compelling enough. :)
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AntiPattern Genius
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> > > Berin,
> > >
> > >
> > > I follow the Anti-Pattern thing since 4 years ago. I like it.
> > > It is a great argument.
> > >
> > > What I disagree is about making the central/introductory
> > > argument for Avalon.
> > >
> > > First show how it is great, THEN show how it avoids bad things.
> >
> >
> > :) How do you propose to show it is great without showing how to
> > avoid bad things?
>
> simple enough. Show current well-designed piece of OOP
> software. Then show how refactoring it to be avalonized is
> easy and has many advantages.
Ho hum.
It's just not compelling enough. :)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AntiPattern Genius
Posted by Leo Simons <le...@apache.org>.
> > Berin,
> >
> >
> > I follow the Anti-Pattern thing since 4 years ago. I like it.
> > It is a great argument.
> >
> > What I disagree is about making the central/introductory
> > argument for Avalon.
> >
> > First show how it is great, THEN show how it avoids bad things.
>
>
> :) How do you propose to show it is great without showing how
> to avoid bad things?
simple enough. Show current well-designed piece of OOP software. Then
show how refactoring it to be avalonized is easy and has many
advantages.
- LSD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AntiPattern Genius
Posted by Berin Loritsch <bl...@apache.org>.
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
>
> Berin,
>
>
> I follow the Anti-Pattern thing since 4 years ago. I like it.
> It is a great argument.
>
> What I disagree is about making the central/introductory
> argument for Avalon.
>
> First show how it is great, THEN show how it avoids bad things.
:) How do you propose to show it is great without showing how
to avoid bad things?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AntiPattern Genius
Posted by Paulo Gaspar <pa...@krankikom.de>.
Berin,
I follow the Anti-Pattern thing since 4 years ago. I like it. It
is a great argument.
What I disagree is about making the central/introductory argument
for Avalon.
First show how it is great, THEN show how it avoids bad things.
Regards,
Paulo
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, June 27, 2002 2:34 PM
> To: 'Avalon Developers List'; paulo.gaspar@krankikom.de
> Subject: RE: AntiPattern Genius
>
>
> > From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> >
> > It is all very nice but goes to that principle Ken mentioned:
> > - It tells your target audience they are stupid.
> >
> > IMHO, the guys that are running away from Avalon are the guys
> > that don't accept to be told wrong. =:o/
>
> Paulo, I couldn't disagree more. Anti-patterns are patterns of
> poor habits from newbies and evil geniouses (sorry I have been
> reading UserFriendly too much). We all know they exist. If
> the user is even marginally experienced, they *know* they have
> either introduced bad code, or have worked on bad code from other
> people.
>
> Anti-patterns represent mistakes that happen with *regularity*,
> and produce *decidedly bad* results.
>
> Presenting the anti-pattern allows the reader to understand what
> they are trying to avoid. It must be followed up by the way we
> apply the corrective pattern.
>
> Avalon, as all component oriented architectures do, has some
> anti-patterns of its own. A5 is aimed at making it harder to
> apply the anti-patterns. In order for A5 to make it, we need
> to explain it in pattern/anti-pattern terms.
>
> Some common _design_ level anti-patterns are (something we could
> not discourage except by documentation):
>
> * Abstracting too early (I know it sounds ironic but more later)
> * Over-componentization
> * Data-centric development
>
> I am not presenting a solution, but here is what they all are.
>
>
> Early Abstraction
> -----------------
> This is when you try to be smarter than you really are. When you
> are designing with reuse in mind, you have a tendency to think of
> every which way your component will be used. It is inevitable that
> you will miss some use cases, and satisfy others that won't ever
> exist in a real system (but it would be real neat...). It leads
> to FS. Solution: focus on your current needs, and adapt the interface
> as you need to.
>
> Over Componentization
> ---------------------
> This is when your component model is too detailed. If your
> component model suggests implementation details, then something is
> wrong. If you need to call seven different components to do one
> simple operation, something is wrong. Solution: focus on what you
> are trying to accomplish, and write your components on the big picture
> needs.
>
> Data-Centric Development
> ------------------------
> This is a cary-over of procedural and OO mindsets. What can happen
> is that you have a very rish object model representing the problem
> domain, but your clients only need a portion of it. Hense you have
> wasted time developing things that noone will use, or the times it
> is used are few and far between. Another side affect is that you
> tend to push the business logic onto the clients instead of
> encapsulating them properly in services/components. When your business
> needs change, you have to change several different clients to make the
> system work properly. Solution: focus on what the system does--the
> data model will follow.
>
> There's more, but these are the design flaws I see in many systems.
> We can't systemically overcome them except by bringing it to people's
> attention.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AntiPattern Genius
Posted by Berin Loritsch <bl...@apache.org>.
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
>
> It is all very nice but goes to that principle Ken mentioned:
> - It tells your target audience they are stupid.
>
> IMHO, the guys that are running away from Avalon are the guys
> that don't accept to be told wrong. =:o/
Paulo, I couldn't disagree more. Anti-patterns are patterns of
poor habits from newbies and evil geniouses (sorry I have been
reading UserFriendly too much). We all know they exist. If
the user is even marginally experienced, they *know* they have
either introduced bad code, or have worked on bad code from other
people.
Anti-patterns represent mistakes that happen with *regularity*,
and produce *decidedly bad* results.
Presenting the anti-pattern allows the reader to understand what
they are trying to avoid. It must be followed up by the way we
apply the corrective pattern.
Avalon, as all component oriented architectures do, has some
anti-patterns of its own. A5 is aimed at making it harder to
apply the anti-patterns. In order for A5 to make it, we need
to explain it in pattern/anti-pattern terms.
Some common _design_ level anti-patterns are (something we could
not discourage except by documentation):
* Abstracting too early (I know it sounds ironic but more later)
* Over-componentization
* Data-centric development
I am not presenting a solution, but here is what they all are.
Early Abstraction
-----------------
This is when you try to be smarter than you really are. When you
are designing with reuse in mind, you have a tendency to think of
every which way your component will be used. It is inevitable that
you will miss some use cases, and satisfy others that won't ever
exist in a real system (but it would be real neat...). It leads
to FS. Solution: focus on your current needs, and adapt the interface
as you need to.
Over Componentization
---------------------
This is when your component model is too detailed. If your
component model suggests implementation details, then something is
wrong. If you need to call seven different components to do one
simple operation, something is wrong. Solution: focus on what you
are trying to accomplish, and write your components on the big picture
needs.
Data-Centric Development
------------------------
This is a cary-over of procedural and OO mindsets. What can happen
is that you have a very rish object model representing the problem
domain, but your clients only need a portion of it. Hense you have
wasted time developing things that noone will use, or the times it
is used are few and far between. Another side affect is that you
tend to push the business logic onto the clients instead of
encapsulating them properly in services/components. When your business
needs change, you have to change several different clients to make the
system work properly. Solution: focus on what the system does--the
data model will follow.
There's more, but these are the design flaws I see in many systems.
We can't systemically overcome them except by bringing it to people's
attention.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AntiPattern Genius
Posted by Paulo Gaspar <pa...@krankikom.de>.
It is all very nice but goes to that principle Ken mentioned:
- It tells your target audience they are stupid.
IMHO, the guys that are running away from Avalon are the guys that don't
accept to be told wrong.
=:o/
Regards,
Paulo Gaspar
> -----Original Message-----
> From: Pete Carapetyan [mailto:pete@datafundamentals.com]
> Sent: Thursday, June 27, 2002 2:00 AM
> To: Avalon Developers List
> Subject: AntiPattern Genius
>
>
> This antipattern thing which Berin brought up has the capability of
> turning Avalon into a totally intuitive, understandable phenomenon, even
> the same Avalon that was not understable before. Only by changing how
> you describe it - starting with antipatterns.. Make it simple without
> having to change anything !
>
> Here is why.
>
> Everybody understands anti-patterns. Few understand patterns, or even
> care to, without a big anti-pattern staring them in the face. Chuck you
> farley, I ain't studying no patterns.
>
> Ask people what they want, they will say they don't know. But give them
> something - anything - and they will read you the riot act for 20
> minutes about how that wasn't what they wanted, and why couldn't you
> have figured that out?. People react to what they see is wrong. That is
> why I am here. I have lived the big ball of mud so long I don't like it
> any more. On the other hand, no big ball of mud, no reason for Avalon,
> unless you are also some kind of re-use freak or something, and even
> then it takes a while to get why OO isn't the answer for all situations.
>
> But there is something even better about this anti-pattern approach !
> The BEST thing about the anti-pattern approach is it allows for *Walking
> The Tree Of Increasing Complexity* as a mode of learning Avalon
> techniques and syntactical approaches. The importance of the tree of
> complexity can not be overstated. This is what makes Avalon
> understandable and intuitive where it was previously neither. As follows:
>
> AVALON INSTRUCTIONS MANUAL:
> -------------------------------
> Here is the simplest most straightforward use of Avalon. Exhibit A. Easy
> for anyone to understand. Applicable in many instances such as blah or
> blah. Simple COP. Addresses the anti-pattern of no re-use, and in
> addition the anti-pattern of big ball of mud. Not much to it. Feast and
> enjoy.
>
> But wait ! When you have a level nnn anti pattern such as blah, you use
> this next more complicated version of Avalon's pattern, Exhibit B. You
> would use this in cases such as blah or blah or blah, for example. Don't
> worry about it unless you need it though.
>
> Next, imagine you have a level nnnn anti pattern such as blahHeh. Now
> that can be a little trickier. In this case, you use an even more
> complicated version of Avalon designed for this anti pattern. Exhibit C.
> A little bit of thought involved , because you have to do xxx and yyyy
> to make it work, and it can blow up on you if you don't watch for zzzzz.
> But it works in the case of, for example blah or blah or blah.
>
> etc. etc etc - all the way up the tree of complexity - from easiest to
> hardest.
>
> Got a project? Want to use Avalon? Take all your pieces, do a quick scan
> on the examples to see which of your components are similar to which
> examples and thus will have to use which level of complexity. You can
> gauge your approach in a manner that allows you to build your skill set
> and your time budget and your own tree of knowledge by starting with the
> simple components first, and gradually migrating to the most complex. Oh
> that one? That's a level nnnn, better learn that after this one. Heh
> cool, found this one already done. Good, it's only a level nnnn. I think
> I'll use that just like it is. And on an on.
>
> Now this is a very intuitive way to learn about the nuances of COP, and
> it is a tree of increasing complexity which you don't even really need
> to learn unless you have the applicable situation. A situation, which,
> by the way can be comparatively easy to spell out for you in plain
> English - as a description of similar situations.
>
> You could even have a cute section challenging people to see the
> anti-pattern in this story, kind of like finding the hidden shoe in this
> figure. A marketing person's dream.
>
> Now consider how we are doing it now.
> 1. Antipatterns are known only by committers - or at least for the most
> part.
> 2. We preach at potential users from up on high - you *should* do this
> because we know better.
> 3. Solutions are 12 levels of iteration deep - each iteration addressing
> an anti-pattern identified (and probably forgotten by some).
> 4. *What's in it for me?* is not even brought up - it is just assumed
> that you know about the antipatterns.
> 5. DENIAL is the pattern that prevents someone from accepting Avalon
> into their life.
> 6-infinity. Plenty more of similar to 1-5 above. Talking about a set of
> marketing anti-patterns !
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>