Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Rise & Fall of Design Patterns:Lessons to learn?

Expand Messages
  • mj4scrum@gmail.com
    ... I hadn t been thinking that myself, but maybe could be persuaded their net effect is positive. I regret a couple of the times I ve deliberately used the
    Message 1 of 11 , Jul 22 2:29 AM
    • 0 Attachment
      On Jul 22, 2013, at 9:50 AM, Agustin Villena <agustin.villena@...> wrote:

      > IMHO DP are less important now that they deserve.

      I hadn't been thinking that myself, but maybe could be persuaded their net effect is positive. I regret a couple of the times I've deliberately used the GOF patterns, and remember working on some code that was a pain because the developer had gone out of his way to use a couple patterns.

      --mj
      (Michael)
    • George Dinwiddie
      Agustin, ... In my experience, the term design patterns is better known than the patterns, themselves. When I was interviewing a lot of programmers, many had
      Message 2 of 11 , Jul 22 7:53 AM
      • 0 Attachment
        Agustin,

        On 7/21/13 9:50 PM, Agustin Villena wrote:
        >
        >
        > Hi all!
        >
        > Design Patterns was one of the great sources of XP in its origins, and
        > therefore of the agile movement, and I still found that creating Design
        > Patterns is a very good form of organizing knowledge, and I´m looking
        > for an approach to document agile practices as method patterns,
        >
        > My questions are.
        > - Which are the great lessons from the Rise & fall of the Design
        > patterns movement?
        >
        > Thanks
        > Agustin Villena
        > @agustinvillena
        >
        > PD: I´m aware that DP is not really dead, and, following the technology
        > hype cycle curve maybe it have its time of hype and now is on the
        > plateau of productivity, but in IMHO DP are less important now that they
        > deserve.

        In my experience, the term "design patterns" is better known than the
        patterns, themselves. When I was interviewing a lot of programmers, many
        had "design patterns" on their resume. When asked which design patterns
        they found most useful in their work, less than a handful could name a
        pattern other than Singleton.

        I suspect that the presentation of information in the pattern format is
        a bit dry for the average person, and that limits the actual understanding.

        - George

        --
        Want to speak at AgileDC October 8, 2013? http://agiledc.org/speak/
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • woynam
        Just because your toolbox contains a hammer, doesn t mean that you need to use it. :-) Design patterns was a major step in improving communication. You didn t
        Message 3 of 11 , Jul 22 9:39 AM
        • 0 Attachment
          Just because your toolbox contains a hammer, doesn't mean that you need to use it. :-)

          Design patterns was a major step in improving communication. You didn't have to sit around for an hour trying to explain your design, as you could just say "Observer pattern", and your fellow team members would understand you. Now, whether an observer was warranted, say over a mediator, was a different matter.

          The DP movement was primarily based on cataloging the vast number of designs already in use. Given that younger developers probably grew up with the patterns, there current importance is probably diminished, but at the time, it was a huge step forward.

          Mark


          --- In scrumdevelopment@yahoogroups.com, "mj4scrum@..." <mj4scrum@...> wrote:
          >
          > On Jul 22, 2013, at 9:50 AM, Agustin Villena <agustin.villena@...> wrote:
          >
          > > IMHO DP are less important now that they deserve.
          >
          > I hadn't been thinking that myself, but maybe could be persuaded their net effect is positive. I regret a couple of the times I've deliberately used the GOF patterns, and remember working on some code that was a pain because the developer had gone out of his way to use a couple patterns.
          >
          > --mj
          > (Michael)
          >
        • Agustin Villena
          Indeed, if we refer to GoF patterns... a local Aspects researcher showed me how applying Observer design pattern actually made the code more difficult to
          Message 4 of 11 , Jul 23 6:10 AM
          • 0 Attachment

            Indeed,  if we refer to GoF patterns... a local Aspects researcher showed me how applying Observer design pattern actually made the code more difficult to maintain (sorry,  I don't have the exact example)

            And some patterns were language dependant (e.g.  Factory was not needed in Delphi)

            But AFAIK Pattern Languages are  the best way to document good recurring solutions in a context, something that agilists need to embrace. Our practices has a specific context of applicability.

            Greetings
            Agustín

            El jul 22, 2013 5:29 AM, "mj4scrum@..." <mj4scrum@...> escribió:
            On Jul 22, 2013, at 9:50 AM, Agustin Villena <agustin.villena@...> wrote:

            > IMHO DP are less important now that they deserve.

            I hadn't been thinking that myself, but maybe could be persuaded their net effect is positive.  I regret a couple of the times I've deliberately used the GOF patterns, and remember working on some code that was a pain because the developer had gone out of his way to use a couple patterns.

            --mj
            (Michael)

            ------------------------------------

            To Post a message, send it to:   scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

            <*> To visit your group on the web, go to:
                http://groups.yahoo.com/group/scrumdevelopment/

            <*> Your email settings:
                Individual Email | Traditional

            <*> To change settings online go to:
                http://groups.yahoo.com/group/scrumdevelopment/join
                (Yahoo! ID required)

            <*> To change settings via email:
                scrumdevelopment-digest@yahoogroups.com
                scrumdevelopment-fullfeatured@yahoogroups.com

            <*> To unsubscribe from this group, send an email to:
                scrumdevelopment-unsubscribe@yahoogroups.com

            <*> Your use of Yahoo! Groups is subject to:
                http://docs.yahoo.com/info/terms/

          • Agustin Villena
            Interesting hypothesis. Maybe we could work a more easier way to show recurring-solutions-for-a-given-context... Maybe our Design Thinking pals could help? ...
            Message 5 of 11 , Jul 23 6:21 AM
            • 0 Attachment

              Interesting hypothesis. Maybe we could work a more easier way to show recurring-solutions-for-a-given-context... Maybe our Design Thinking pals could help?
              :-)

              Saludos
              Agustín

              El jul 22, 2013 10:55 AM, "George Dinwiddie" <lists@...> escribió:
              Agustin,

              On 7/21/13 9:50 PM, Agustin Villena wrote:
              >
              >
              > Hi all!
              >
              > Design Patterns was one of the great sources of XP in its origins, and
              > therefore of the agile movement, and I still found that creating Design
              > Patterns is a very good form of organizing knowledge, and I´m looking
              > for an approach to document agile practices as method patterns,
              >
              > My questions are.
              > - Which are the great lessons from the Rise & fall of the  Design
              > patterns movement?
              >
              > Thanks
              >    Agustin Villena
              >    @agustinvillena
              >
              > PD: I´m aware that DP is not really dead, and, following the technology
              > hype cycle  curve maybe it have its time of hype and now is on the
              > plateau of productivity, but in IMHO DP are less important now that they
              > deserve.

              In my experience, the term "design patterns" is better known than the
              patterns, themselves. When I was interviewing a lot of programmers, many
              had "design patterns" on their resume. When asked which design patterns
              they found most useful in their work, less than a handful could name a
              pattern other than Singleton.

              I suspect that the presentation of information in the pattern format is
              a bit dry for the average person, and that limits the actual understanding.

                - George

              --
                 Want to speak at AgileDC October 8, 2013?  http://agiledc.org/speak/
                ----------------------------------------------------------------------
                 * George Dinwiddie *                      http://blog.gdinwiddie.com
                 Software Development                    http://www.idiacomputing.com
                 Consultant and Coach                    http://www.agilemaryland.org
                ----------------------------------------------------------------------



              ------------------------------------

              To Post a message, send it to:   scrumdevelopment@...
              To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

              <*> To visit your group on the web, go to:
                  http://groups.yahoo.com/group/scrumdevelopment/

              <*> Your email settings:
                  Individual Email | Traditional

              <*> To change settings online go to:
                  http://groups.yahoo.com/group/scrumdevelopment/join
                  (Yahoo! ID required)

              <*> To change settings via email:
                  scrumdevelopment-digest@yahoogroups.com
                  scrumdevelopment-fullfeatured@yahoogroups.com

              <*> To unsubscribe from this group, send an email to:
                  scrumdevelopment-unsubscribe@yahoogroups.com

              <*> Your use of Yahoo! Groups is subject to:
                  http://docs.yahoo.com/info/terms/

            • Agustin Villena
              Thank you all for the great feedback Many answered questioning if Design Patterns has really fallen (a fair point), but that was not my point. My real
              Message 6 of 11 , Jul 24 11:53 AM
              • 0 Attachment

                Thank you all for the great feedback

                Many answered questioning if Design Patterns has really  fallen (a fair point), but that was not my point.

                My real question is:

                If we want to use Patterns to document and communicate Agile Practices,  which pitfalls of the early Design Patterns movement we should avoid? (for the goal of being really relevant for agile practitioners)

                Saludos
                Agustín

                El jul 21, 2013 9:50 PM, "Agustin Villena" <agustin.villena@...> escribió:
                Hi all!

                Design Patterns was one of the great sources of XP in its origins, and therefore of the agile movement, and I still found that creating Design Patterns is a very good form of organizing knowledge, and I´m looking for an approach to document agile practices as method patterns,

                My questions are.
                - Which are the great lessons from the Rise & fall of the  Design patterns movement?

                Thanks
                  Agustin Villena
                  @agustinvillena

                PD: I´m aware that DP is not really dead, and, following the technology hype cycle  curve maybe it have its time of hype and now is on the plateau of productivity, but in IMHO DP are less important now that they deserve.
              • Erkki Pöyhönen
                An idea: Ivar Jacobson (a bloke I appreciate very much for what he has done for object-oriented development, requirements and processes) started recently a
                Message 7 of 11 , Jul 25 1:04 AM
                • 0 Attachment
                  An idea: Ivar Jacobson (a bloke I appreciate very much for what he has done for object-oriented development, requirements and processes) started recently a bold movement in defining practices for SW development in various contexts and for various uses. He is about the best positioned person to do that after being part of several major shifts in our thinking about SW development.  His model of essential practices is here: http://www.ivarjacobson.com/practices/

                  I assume (after initial browsing) that this would be a wonderful initiative to tag along, and especially make sure that awareness of context-dependency is not lost when various consultants try to cash on this and aim to make things applicable for larger audience :-)

                  About the original question: After the GoF patterns the pattern thinking has expanded to various areas with sometimes great benefits. What GoF did for design the Buschmann book did for architectures and Robert Binder for SW testing (good book, but onnly capitalised the idea without involving a practitioner network or initiative to raise interest) after the testing patterns activities started by Brian Marick dried up. The patterns are one of those things per original story by Alexander: condensed common wisdom, more a heuristic rather than strict rule, and after learning it a person can not necessarily tell where did he/she learn the idea.  When we read about BigBallOfMud (BBOM) as an architecture antipattern to avoid, we all nod our heads knowingly and say, "yep, seen that one" but at the same time we become more aware of the risk and have a name for it in future discussions. There still is no need for a tool to measure "BBOM-factor" in a generic case.

                  In XP case IMHO the main practices were reasonably well described and substantiated in the original Kent book, even though they were not in pattern format. Moving beyond XP practices we have more complicated world of sometimes conflicting but at least different priorities and different implied development contexts. So what do you think what is missing?
                  - better explanations of where and how to apply each?  (close to a typical good pattern substance)
                  - case studies of each practice? (references / examples of use are part of a pattern)
                  - pointers for current tool support wherever available?
                  - just systematic presentation of practices (for future developer generations) we current developers have learned about in a less systematic way?
                  - something else?

                  If one says "agile practices" that can include almost anything as very many practices can have a potential in agile where most of them are not necessarily relevant or beneficial on any given case. Considering a bottom-up aproach --starting from narrower world view, like XP or Kanban specifically might be an easier start, IMHO. Then it would be possible to identify overlap and common themes.

                  Context-dependency is a great idea and sometimes consensus of applicability is achieved faster (this is all about what many people have seen to work and what not), but very hard to describe in a general case (consider all the various ways one could define "the context"). Good luck for your idea, I would want to see the results!

                  Cheers, Erkki



                  2013/7/24 Agustin Villena <agustin.villena@...>
                   

                  Thank you all for the great feedback

                  Many answered questioning if Design Patterns has really  fallen (a fair point), but that was not my point.

                  My real question is:

                  If we want to use Patterns to document and communicate Agile Practices,  which pitfalls of the early Design Patterns movement we should avoid? (for the goal of being really relevant for agile practitioners)

                  Saludos
                  Agustín

                  El jul 21, 2013 9:50 PM, "Agustin Villena" <agustin.villena@...> escribió:

                  Hi all!

                  Design Patterns was one of the great sources of XP in its origins, and therefore of the agile movement, and I still found that creating Design Patterns is a very good form of organizing knowledge, and I´m looking for an approach to document agile practices as method patterns,

                  My questions are.
                  - Which are the great lessons from the Rise & fall of the  Design patterns movement?

                  Thanks
                    Agustin Villena
                    @agustinvillena

                  PD: I´m aware that DP is not really dead, and, following the technology hype cycle  curve maybe it have its time of hype and now is on the plateau of productivity, but in IMHO DP are less important now that they deserve.




                  --
                  Erkki Pöyhönen
                  eeaapee@...
                  http://picasaweb.google.com/eeaapee/
                • Agustin Villena
                  Hi Erkki! About Jacobson, I ve browsed some pages about hus SEMAT initiative. I value Ivar ideas, but I have some issues about these initiatives being from an
                  Message 8 of 11 , Jul 25 5:29 AM
                  • 0 Attachment

                    Hi Erkki!

                    About Jacobson, I've browsed some pages about hus SEMAT initiative.
                    I value Ivar ideas, but I have some issues about these initiatives being from an ivory tower (I'm a Aristotle fan,  not Platonic)

                    Answering your questions :

                    "So what do you think what is missing?

                    > - better explanations of where and how to apply each?  (close to a typical good pattern substance)
                    > - case studies of each practice? (references / examples of use are part of a pattern)
                    > - pointers for current tool support wherever available?
                    > - just systematic presentation of practices (for future developer generations) we current developers have learned about in a less systematic way?
                    > - something else?"

                    As

                    El jul 25, 2013 4:04 AM, "Erkki Pöyhönen" <eeaapee@...> escribió:

                    >
                    >
                    >
                    > An idea: Ivar Jacobson (a bloke I appreciate very much for what he has done for object-oriented development, requirements and processes) started recently a bold movement in defining practices for SW development in various contexts and for various uses. He is about the best positioned person to do that after being part of several major shifts in our thinking about SW development.  His model of essential practices is here: http://www.ivarjacobson.com/practices/
                    >
                    > I assume (after initial browsing) that this would be a wonderful initiative to tag along, and especially make sure that awareness of context-dependency is not lost when various consultants try to cash on this and aim to make things applicable for larger audience :-)
                    >
                    > About the original question: After the GoF patterns the pattern thinking has expanded to various areas with sometimes great benefits. What GoF did for design the Buschmann book did for architectures and Robert Binder for SW testing (good book, but onnly capitalised the idea without involving a practitioner network or initiative to raise interest) after the testing patterns activities started by Brian Marick dried up. The patterns are one of those things per original story by Alexander: condensed common wisdom, more a heuristic rather than strict rule, and after learning it a person can not necessarily tell where did he/she learn the idea.  When we read about BigBallOfMud (BBOM) as an architecture antipattern to avoid, we all nod our heads knowingly and say, "yep, seen that one" but at the same time we become more aware of the risk and have a name for it in future discussions. There still is no need for a tool to measure "BBOM-factor" in a generic case.
                    >
                    > In XP case IMHO the main practices were reasonably well described and substantiated in the original Kent book, even though they were not in pattern format. Moving beyond XP practices we have more complicated world of sometimes conflicting but at least different priorities and different implied development contexts. So what do you think what is missing?
                    > - better explanations of where and how to apply each?  (close to a typical good pattern substance)
                    > - case studies of each practice? (references / examples of use are part of a pattern)
                    > - pointers for current tool support wherever available?
                    > - just systematic presentation of practices (for future developer generations) we current developers have learned about in a less systematic way?
                    > - something else?
                    >
                    > If one says "agile practices" that can include almost anything as very many practices can have a potential in agile where most of them are not necessarily relevant or beneficial on any given case. Considering a bottom-up aproach --starting from narrower world view, like XP or Kanban specifically might be an easier start, IMHO. Then it would be possible to identify overlap and common themes.
                    >
                    > Context-dependency is a great idea and sometimes consensus of applicability is achieved faster (this is all about what many people have seen to work and what not), but very hard to describe in a general case (consider all the various ways one could define "the context"). Good luck for your idea, I would want to see the results!
                    >
                    > Cheers, Erkki
                    >
                    >
                    >
                    > 2013/7/24 Agustin Villena <agustin.villena@...>
                    >>
                    >>  
                    >>
                    >> Thank you all for the great feedback
                    >>
                    >> Many answered questioning if Design Patterns has really  fallen (a fair point), but that was not my point.
                    >>
                    >> My real question is:
                    >>
                    >> If we want to use Patterns to document and communicate Agile Practices,  which pitfalls of the early Design Patterns movement we should avoid? (for the goal of being really relevant for agile practitioners)
                    >>
                    >> Saludos
                    >> Agustín
                    >>
                    >> El jul 21, 2013 9:50 PM, "Agustin Villena" <agustin.villena@...> escribió:
                    >>
                    >>> Hi all!
                    >>>
                    >>> Design Patterns was one of the great sources of XP in its origins, and therefore of the agile movement, and I still found that creating Design Patterns is a very good form of organizing knowledge, and I´m looking for an approach to document agile practices as method patterns,
                    >>>
                    >>> My questions are.
                    >>> - Which are the great lessons from the Rise & fall of the  Design patterns movement?
                    >>>
                    >>> Thanks
                    >>>   Agustin Villena
                    >>>   @agustinvillena
                    >>>
                    >>> PD: I´m aware that DP is not really dead, and, following the technology hype cycle  curve maybe it have its time of hype and now is on the plateau of productivity, but in IMHO DP are less important now that they deserve.
                    >
                    >
                    >
                    >
                    > --
                    > Erkki Pöyhönen
                    > eeaapee@...
                    > http://picasaweb.google.com/eeaapee/
                    >
                    >
                    >

                  • Agustin Villena
                    Hi Erkki! About Jacobson, I ve browsed some pages about hus SEMAT initiative. I value Ivar ideas, but I have some issues about these initiatives being from an
                    Message 9 of 11 , Jul 25 6:08 AM
                    • 0 Attachment

                      Hi Erkki!

                      About Jacobson, I've browsed some pages about hus SEMAT initiative.
                      I value Ivar ideas, but I have some issues about these initiatives being from an ivory tower (I'm a Aristotle fan,  not Platonic)

                      Answering your questions :

                      "So what do you think what is missing?
                      - better explanations of where and how to apply each?  (close to a typical good pattern substance)
                      - case studies of each practice? (references / examples of use are part of a patterns
                      "

                      Exactly that.
                      All our practices are a result of principles in a specific context.

                      But some methodologists try to enforce a vendor-lock-in claiming the One-True-Way to do things (e.g.  Scrum-but or shallow-kanban)

                      This claim is enforced by our educational system  (as brilliantly exposed by Sir Ken Robinson in https://www.youtube.com/watch?v=zDZFcDGpL4U) that kills our capacity to do "divergent thinking", i.e. the great majority of us are hardwired to use only one solution without understanding the original problem and exploring other ways (by the way,  this is a core skill to do Dimensional Planning)

                      After coaching more than 50 agile software projects and extending agile to other conyexts like creative agencies, lawyers,  journalists and k-12 teachers  I can sustain that I never ever will apply an agile method by the book.

                      Therefore I think that it would be great to show our practices as recurring solution derived to apply some principle in some specific contexts.

                      For example, one of the very first agile development practices that I successfully apply was Pair Programming. Some people said that under the Lean principles that practice is a waste of effort.
                      Kent Beck recent answered this question in quora ( http://www.quora.com/Is-pair-programming-worth-the-trade-off-in-engineering-resources) explicitly defining a context of applicability.

                      " (Pair Programming is worth) when:
                      - The problem space is big and unknown. You don't know what exact problem you are solving and the probability is high that any solution you find will change your understanding of the problem.
                      - The solution space is big and unknown. You are working with technology you don't fully understand and the chances are that any solution you find will change your understanding of what constitutes an effective solution.
                      - You need to build relationships on a team."

                      I really think that our understanding and coaching of agile practices will be really improved with this applicability-context information.

                      Best Regards
                      Agustin


                      - pointers for current tool support wherever available?
                      - just systematic presentation of practices (for future developer generations) we current developers have learned about in a less systematic way?
                      - something else?"

                      > As
                      >
                      > El jul 25, 2013 4:04 AM, "Erkki Pöyhönen" <eeaapee@...> escribió:
                      > >
                      > >
                      > >
                      > > An idea: Ivar Jacobson (a bloke I appreciate very much for what he has done for object-oriented development, requirements and processes) started recently a bold movement in defining practices for SW development in various contexts and for various uses. He is about the best positioned person to do that after being part of several major shifts in our thinking about SW development.  His model of essential practices is here: http://www.ivarjacobson.com/practices/
                      > >
                      > > I assume (after initial browsing) that this would be a wonderful initiative to tag along, and especially make sure that awareness of context-dependency is not lost when various consultants try to cash on this and aim to make things applicable for larger audience :-)
                      > >
                      > > About the original question: After the GoF patterns the pattern thinking has expanded to various areas with sometimes great benefits. What GoF did for design the Buschmann book did for architectures and Robert Binder for SW testing (good book, but onnly capitalised the idea without involving a practitioner network or initiative to raise interest) after the testing patterns activities started by Brian Marick dried up. The patterns are one of those things per original story by Alexander: condensed common wisdom, more a heuristic rather than strict rule, and after learning it a person can not necessarily tell where did he/she learn the idea.  When we read about BigBallOfMud (BBOM) as an architecture antipattern to avoid, we all nod our heads knowingly and say, "yep, seen that one" but at the same time we become more aware of the risk and have a name for it in future discussions. There still is no need for a tool to measure "BBOM-factor" in a generic case.
                      > >
                      > > In XP case IMHO the main practices were reasonably well described and substantiated in the original Kent book, even though they were not in pattern format. Moving beyond XP practices we have more complicated world of sometimes conflicting but at least different priorities and different implied development contexts. So what do you think what is missing?
                      > > - better explanations of where and how to apply each?  (close to a typical good pattern substance)
                      > > - case studies of each practice? (references / examples of use are part of a pattern)
                      > > - pointers for current tool support wherever available?
                      > > - just systematic presentation of practices (for future developer generations) we current developers have learned about in a less systematic way?
                      > > - something else?
                      > >
                      > > If one says "agile practices" that can include almost anything as very many practices can have a potential in agile where most of them are not necessarily relevant or beneficial on any given case. Considering a bottom-up aproach --starting from narrower world view, like XP or Kanban specifically might be an easier start, IMHO. Then it would be possible to identify overlap and common themes.
                      > >
                      > > Context-dependency is a great idea and sometimes consensus of applicability is achieved faster (this is all about what many people have seen to work and what not), but very hard to describe in a general case (consider all the various ways one could define "the context"). Good luck for your idea, I would want to see the results!
                      > >
                      > > Cheers, Erkki
                      > >
                      > >
                      > >
                      > > 2013/7/24 Agustin Villena <agustin.villena@...>
                      > >>
                      > >>  
                      > >>
                      > >> Thank you all for the great feedback
                      > >>
                      > >> Many answered questioning if Design Patterns has really  fallen (a fair point), but that was not my point.
                      > >>
                      > >> My real question is:
                      > >>
                      > >> If we want to use Patterns to document and communicate Agile Practices,  which pitfalls of the early Design Patterns movement we should avoid? (for the goal of being really relevant for agile practitioners)
                      > >>
                      > >> Saludos
                      > >> Agustín
                      > >>
                      > >> El jul 21, 2013 9:50 PM, "Agustin Villena" <agustin.villena@...> escribió:
                      > >>
                      > >>> Hi all!
                      > >>>
                      > >>> Design Patterns was one of the great sources of XP in its origins, and therefore of the agile movement, and I still found that creating Design Patterns is a very good form of organizing knowledge, and I´m looking for an approach to document agile practices as method patterns,
                      > >>>
                      > >>> My questions are.
                      > >>> - Which are the great lessons from the Rise & fall of the  Design patterns movement?
                      > >>>
                      > >>> Thanks
                      > >>>   Agustin Villena
                      > >>>   @agustinvillena
                      > >>>
                      > >>> PD: I´m aware that DP is not really dead, and, following the technology hype cycle  curve maybe it have its time of hype and now is on the plateau of productivity, but in IMHO DP are less important now that they deserve.
                      > >
                      > >
                      > >
                      > >
                      > > --
                      > > Erkki Pöyhönen
                      > > eeaapee@...
                      > > http://picasaweb.google.com/eeaapee/
                      > >
                      > >
                      > >

                    Your message has been successfully submitted and would be delivered to recipients shortly.