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

Rise & Fall of Design Patterns:Lessons to learn?

Expand Messages
  • Agustin Villena
    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
    Message 1 of 11 , Jul 21, 2013
    • 0 Attachment
      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.
    • Markus Gaertner
      Hi Agustin, you may want to get in touch with the folks around Scrum PLoP: http://www.scrumplop.org They already seem to do that for Scrum. Best Markus On Mon,
      Message 2 of 11 , Jul 22, 2013
      • 0 Attachment
        Hi Agustin,

        you may want to get in touch with the folks around Scrum PLoP: http://www.scrumplop.org They already seem to do that for Scrum.

        Best
        Markus


        On Mon, Jul 22, 2013 at 3:50 AM, Agustin Villena <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.





        --
        Dipl.-Inform. Markus Gärtner
        Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development
      • 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 3 of 11 , Jul 22, 2013
        • 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 4 of 11 , Jul 22, 2013
          • 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 5 of 11 , Jul 22, 2013
            • 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 6 of 11 , Jul 23, 2013
              • 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 7 of 11 , Jul 23, 2013
                • 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 8 of 11 , Jul 24, 2013
                  • 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 9 of 11 , Jul 25, 2013
                    • 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 10 of 11 , Jul 25, 2013
                      • 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 11 of 11 , Jul 25, 2013
                        • 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.