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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.