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

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

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