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

Question about Architecture

Expand Messages
  • Matt Heusser
    My first exposure to XP was reading the Extreme Programming: Installed. I was struck and impressed in the whole team/consensus based/emergent design ideal.
    Message 1 of 29 , Oct 30, 2007
    • 0 Attachment
      My first exposure to XP was reading the "Extreme Programming: Installed."

      I was struck and impressed in the whole team/consensus based/emergent design
      ideal.

      Recently I've begun to hear more and more rumblings around the idea of
      "Agile Architecture."

      I ask this in the XP list, because XP was well-established and did not have
      a role for Architect at the snowbird conference in 2001 when the Manifesto
      was penned:

      What does Agile Architecture mean? and how would it be done?

      (Feel free to answer something like "I don't know. Nobody else does either.
      Have you read who needs an architect by Martin Fowler?" - I think that could
      add to a lively discussion. :-)

      Regards,

      --
      Matthew Heusser,
      Blog: http://xndev.blogspot.com

      "Objectivity cannot be equated with mental blankness; rather, objectivity
      resides in recognizing your preferences and then subjecting them to
      especially harsh scrutiny � and also in a willingness to revise or abandon
      your theories when the tests fail (as they usually do)."
      - Stephen Jay Gould


      [Non-text portions of this message have been removed]
    • Wilson, Michael
      This to me is one of the striking things about TDD specifically (and it carrys through to Xp in the large well enough that I don t think it s off point.) My
      Message 2 of 29 , Oct 30, 2007
      • 0 Attachment
        This to me is one of the striking things about TDD specifically (and it
        carrys through to Xp in the large well enough that I don't think it's
        off point.) My take on what "Agile Architecture" is about is that you
        don't pre-build your infrastructure. The months of up-front work of
        developing (for instance) your own homegrown C++ reactor classes,
        messaging infrastructure or persistence components is deferred until you
        are actually implementing stories that require a piece of that
        subsystem.

        In TDD you see this on the small scale quite readily. The design
        emerges slowly from only that which is necessary to produce the unit and
        pass the test, and no more. I've personally found that TDD takes the
        place of the otherwise arbitrary feeling of safety that developers tend
        to seek by writing a bunch of infrastructure code up front.

        Sure, getting some ducks in a row up front makes sense for a larger
        system. But it's a whiteboard discussion, not a huge honkin wap of UML
        documents.

        On the other side, when I've worked in a shop that has heavy
        infrastructure (usually the result of some "architecture/tools" group
        with no business sponsorship) then far too much of the coding effort has
        been focused on adapting to those tools and systems.

        The design that results from this evolution is really quite something.

        Or... did I misunderstand completely?

        - Mike

        -----Original Message-----
        From: extremeprogramming@yahoogroups.com
        [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Matt Heusser
        Sent: Tuesday, October 30, 2007 2:26 PM
        To: extremeprogramming@yahoogroups.com
        Subject: [XP] Question about Architecture

        My first exposure to XP was reading the "Extreme Programming:
        Installed."

        I was struck and impressed in the whole team/consensus based/emergent
        design ideal.

        Recently I've begun to hear more and more rumblings around the idea of
        "Agile Architecture."

        I ask this in the XP list, because XP was well-established and did not
        have a role for Architect at the snowbird conference in 2001 when the
        Manifesto was penned:

        What does Agile Architecture mean? and how would it be done?

        (Feel free to answer something like "I don't know. Nobody else does
        either.
        Have you read who needs an architect by Martin Fowler?" - I think that
        could add to a lively discussion. :-)

        Regards,

        --
        Matthew Heusser,
        Blog: http://xndev.blogspot.com

        "Objectivity cannot be equated with mental blankness; rather,
        objectivity resides in recognizing your preferences and then subjecting
        them to especially harsh scrutiny - and also in a willingness to revise
        or abandon your theories when the tests fail (as they usually do)."
        - Stephen Jay Gould


        [Non-text portions of this message have been removed]



        To Post a message, send it to: extremeprogramming@...

        To Unsubscribe, send a blank message to:
        extremeprogramming-unsubscribe@...

        ad-free courtesy of objectmentor.com
        Yahoo! Groups Links



        -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
        This message is for the named person's use only. This communication is for
        informational purposes only and has been obtained from sources believed to
        be reliable, but it is not necessarily complete and its accuracy cannot be
        guaranteed. It is not intended as an offer or solicitation for the purchase
        or sale of any financial instrument or as an official confirmation of any
        transaction. Moreover, this material should not be construed to contain any
        recommendation regarding, or opinion concerning, any security. It may
        contain confidential, proprietary or legally privileged information. No
        confidentiality or privilege is waived or lost by any mistransmission. If
        you receive this message in error, please immediately delete it and all
        copies of it from your system, destroy any hard copies of it and notify the
        sender. You must not, directly or indirectly, use, disclose, distribute,
        print, or copy any part of this message if you are not the intended
        recipient. Any views expressed in this message are those of the individual
        sender, except where the message states otherwise and the sender is
        authorized to state them to be the views of any such entity.

        Securities products and services provided to Canadian investors are offered
        by ITG Canada Corp. (member CIPF and IDA), an affiliate of Investment
        Technology Group, Inc.

        ITG Inc. and/or its affiliates reserves the right to monitor and archive
        all electronic communications through its network.

        ITG Inc. Member NASD, SIPC
        -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
      • Kent Beck
        Dear Michael, I too have increasingly heard the phrase agile architecture . I addressed a group of architects at a big bank in New York on the subject last
        Message 3 of 29 , Oct 30, 2007
        • 0 Attachment
          Dear Michael,

          I too have increasingly heard the phrase "agile architecture". I addressed a
          group of architects at a big bank in New York on the subject last week. I
          see it as a good sign that more people are engaging in the "how can we be
          agile" discussion.

          I once sat on a plane next to an architect for Visa International's
          infrastructure. He explained their TDD practice to me. They had a monster
          stress testing infrastructure. They would improve the stress tests until the
          system broke. Then they would do just what they needed to to pass the test.
          They didn't put in architecture they didn't need because every element has a
          chance for unintended interactions with every other element. The more
          complicated the architecture, the lower the reliability.

          It seems to me that establishing principles is a good way to have a
          productive discussion about architecture. If everyone can agree that flow is
          important, for example, then you have a head start on how to work together.
          If you can determine that some people care about flow while others care
          about other principles, then you can avoid a lot of fruitless disagreement
          about practices.

          Regards,

          Kent Beck
          Three Rivers Institute


          _____

          From: extremeprogramming@yahoogroups.com
          [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Wilson, Michael
          Sent: Tuesday, October 30, 2007 11:38 AM
          To: extremeprogramming@yahoogroups.com
          Subject: RE: [XP] Question about Architecture




          This to me is one of the striking things about TDD specifically (and it
          carrys through to Xp in the large well enough that I don't think it's
          off point.) My take on what "Agile Architecture" is about is that you
          don't pre-build your infrastructure. The months of up-front work of
          developing (for instance) your own homegrown C++ reactor classes,
          messaging infrastructure or persistence components is deferred until you
          are actually implementing stories that require a piece of that
          subsystem.

          In TDD you see this on the small scale quite readily. The design
          emerges slowly from only that which is necessary to produce the unit and
          pass the test, and no more. I've personally found that TDD takes the
          place of the otherwise arbitrary feeling of safety that developers tend
          to seek by writing a bunch of infrastructure code up front.

          Sure, getting some ducks in a row up front makes sense for a larger
          system. But it's a whiteboard discussion, not a huge honkin wap of UML
          documents.

          On the other side, when I've worked in a shop that has heavy
          infrastructure (usually the result of some "architecture/tools" group
          with no business sponsorship) then far too much of the coding effort has
          been focused on adapting to those tools and systems.

          The design that results from this evolution is really quite something.

          Or... did I misunderstand completely?

          - Mike

          -----Original Message-----
          From: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
          yahoogroups.com
          [mailto:extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
          yahoogroups.com] On Behalf Of Matt Heusser
          Sent: Tuesday, October 30, 2007 2:26 PM
          To: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
          yahoogroups.com
          Subject: [XP] Question about Architecture

          My first exposure to XP was reading the "Extreme Programming:
          Installed."

          I was struck and impressed in the whole team/consensus based/emergent
          design ideal.

          Recently I've begun to hear more and more rumblings around the idea of
          "Agile Architecture."

          I ask this in the XP list, because XP was well-established and did not
          have a role for Architect at the snowbird conference in 2001 when the
          Manifesto was penned:

          What does Agile Architecture mean? and how would it be done?

          (Feel free to answer something like "I don't know. Nobody else does
          either.
          Have you read who needs an architect by Martin Fowler?" - I think that
          could add to a lively discussion. :-)

          Regards,

          --
          Matthew Heusser,
          Blog: http://xndev. <http://xndev.blogspot.com> blogspot.com

          "Objectivity cannot be equated with mental blankness; rather,
          objectivity resides in recognizing your preferences and then subjecting
          them to especially harsh scrutiny - and also in a willingness to revise
          or abandon your theories when the tests fail (as they usually do)."
          - Stephen Jay Gould

          [Non-text portions of this message have been removed]

          To Post a message, send it to: extremeprogramming@
          <mailto:extremeprogramming%40eGroups.com> eGroups.com

          To Unsubscribe, send a blank message to:
          extremeprogramming- <mailto:extremeprogramming-unsubscribe%40eGroups.com>
          unsubscribe@...

          ad-free courtesy of objectmentor.com
          Yahoo! Groups Links

          -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
          This message is for the named person's use only. This communication is for
          informational purposes only and has been obtained from sources believed to
          be reliable, but it is not necessarily complete and its accuracy cannot be
          guaranteed. It is not intended as an offer or solicitation for the purchase
          or sale of any financial instrument or as an official confirmation of any
          transaction. Moreover, this material should not be construed to contain any
          recommendation regarding, or opinion concerning, any security. It may
          contain confidential, proprietary or legally privileged information. No
          confidentiality or privilege is waived or lost by any mistransmission. If
          you receive this message in error, please immediately delete it and all
          copies of it from your system, destroy any hard copies of it and notify the
          sender. You must not, directly or indirectly, use, disclose, distribute,
          print, or copy any part of this message if you are not the intended
          recipient. Any views expressed in this message are those of the individual
          sender, except where the message states otherwise and the sender is
          authorized to state them to be the views of any such entity.

          Securities products and services provided to Canadian investors are offered
          by ITG Canada Corp. (member CIPF and IDA), an affiliate of Investment
          Technology Group, Inc.

          ITG Inc. and/or its affiliates reserves the right to monitor and archive
          all electronic communications through its network.

          ITG Inc. Member NASD, SIPC
          -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-





          [Non-text portions of this message have been removed]
        • J. B. Rainsberger
          ... When I hear architecture I think high-level design . On that basis, I can only imagine that agile architecture refers to letting even the high-level
          Message 4 of 29 , Nov 9, 2007
          • 0 Attachment
            Matt Heusser wrote:
            > My first exposure to XP was reading the "Extreme Programming: Installed."
            >
            > I was struck and impressed in the whole team/consensus based/emergent design
            > ideal.
            >
            > Recently I've begun to hear more and more rumblings around the idea of
            > "Agile Architecture."
            >
            > I ask this in the XP list, because XP was well-established and did not have
            > a role for Architect at the snowbird conference in 2001 when the Manifesto
            > was penned:
            >
            > What does Agile Architecture mean? and how would it be done?

            When I hear "architecture" I think "high-level design". On that basis, I
            can only imagine that "agile architecture" refers to letting even the
            high-level design evolve: not being afraid to continue refactoring when
            you start changing one of the five most important concepts in your code
            base.
            --
            J. B. (Joe) Rainsberger :: http://www.jbrains.ca
            Your guide to software craftsmanship
            JUnit Recipes: Practical Methods for Programmer Testing
            2005 Gordon Pask Award for contribution Agile Software Practice
          • Matt Heusser
            ... For once, I completely agree with J.B. Sweet. Now, that said: What s design? Is it a noun that you can point to, or a verb - an activity. ? If it s a
            Message 5 of 29 , Nov 9, 2007
            • 0 Attachment
              J.B. Rainsberger wrote:

              >When I hear "architecture" I think "high-level design".
              >On that basis, I can only imagine that "agile architecture"
              >refers to letting even the high-level design evolve: not being
              >afraid to continue refactoring when you start changing one
              >of the five most important concepts in your code base.
              >

              For once, I completely agree with J.B. Sweet.

              Now, that said: What's design?

              Is it a noun that you can point to, or a verb - an activity. ?
              If it's a noun, can you define it?

              Seriously, I'm happy with J.B.'s definition - I think it works as a
              operational definition. Much like the definition for Quality or that other
              thing, saying "I know it when I see it" can fail philosophically but succeed
              operationally.

              Still, I think there might be some value in pursuing this. Does anyone have
              an answer to propose?


              --
              Matthew Heusser,
              Blog: http://xndev.blogspot.com

              "Objectivity cannot be equated with mental blankness; rather, objectivity
              resides in recognizing your preferences and then subjecting them to
              especially harsh scrutiny � and also in a willingness to revise or abandon
              your theories when the tests fail (as they usually do)."
              - Stephen Jay Gould


              [Non-text portions of this message have been removed]
            • Dale Emery
              Hi Matt, ... I ll offer my definitions. A verb form: Design is the act of specifying the selection, organization, and control of elements of technology to
              Message 6 of 29 , Nov 9, 2007
              • 0 Attachment
                Hi Matt,

                > Does anyone have an answer to propose?

                I'll offer my definitions.

                A verb form: Design is the act of specifying the selection,
                organization, and control of elements of technology to satisfy
                system responsibilities.

                A noun form: Design is a blueprint for the selection,
                organization, and control of elements of technology to satisfy
                system responsibilities.

                I adapted those definitions from a definition I learned from a
                very smart guy named III.

                There's another noun form that I don't have the right words for
                yet: The design of a system is the set of structural and control
                patterns within the system that determine the system's response
                to stimuli. Not quite right, but it's the best I can do at 5:30am.

                Where my other definitions are about descriptions of a system,
                this last one is about a set of patterns inherent in the system
                itself, independent of any description of those patterns. Every
                identifiable system has a design, whether or not anybody or
                anything has ever described it.

                I also have a definition of architecture: Architecture is the
                set of design elements that most strongly influence the quality
                attributes of the system.

                One consequence of this definition is that you can't divide
                design elements cleanly into architectural and non-architectural
                elements. Architectural significance is a not a binary variable
                but a continuous one, perhaps best construed as a comparison:
                Design element X is more architecturally significant than design
                element Y. That is, design element X influences the system's
                quality attributes more strongly than does design element Y.

                Something like that.

                Dale

                --
                Dale Emery, Consultant
                Inspiring Leadership for Software People
                Web: http://www.dhemery.com
                Weblog: http://www.dhemery.com/cwd

                Horse sense is what a horse has that keeps him from betting on
                people. --W. C. Fields
              • Marco Dorantes
                Some of my ramblings about the subject of design: http://blogs.msdn.com/marcod/archive/2005/04/03/UnconsciousDesignDefined .aspx
                Message 7 of 29 , Nov 9, 2007
                • 0 Attachment
                  Some of my ramblings about the subject of design:

                  http://blogs.msdn.com/marcod/archive/2005/04/03/UnconsciousDesignDefined\
                  .aspx
                  <http://blogs.msdn.com/marcod/archive/2005/04/03/UnconsciousDesignDefine\
                  d.aspx>


                  --- In extremeprogramming@yahoogroups.com, "Matt Heusser"
                  <matt.heusser@...> wrote:
                  >
                  > J.B. Rainsberger wrote:
                  >
                  > >When I hear "architecture" I think "high-level design".
                  > >On that basis, I can only imagine that "agile architecture"
                  > >refers to letting even the high-level design evolve: not being
                  > >afraid to continue refactoring when you start changing one
                  > >of the five most important concepts in your code base.
                  > >
                  >
                  > For once, I completely agree with J.B. Sweet.
                  >
                  > Now, that said: What's design?
                  >
                  > Is it a noun that you can point to, or a verb - an activity. ?
                  > If it's a noun, can you define it?
                  >
                  > Seriously, I'm happy with J.B.'s definition - I think it works as a
                  > operational definition. Much like the definition for Quality or that
                  other
                  > thing, saying "I know it when I see it" can fail philosophically but
                  succeed
                  > operationally.
                  >
                  > Still, I think there might be some value in pursuing this. Does anyone
                  have
                  > an answer to propose?
                  >
                  >
                  > --
                  > Matthew Heusser,
                  > Blog: http://xndev.blogspot.com
                  >
                  > "Objectivity cannot be equated with mental blankness; rather,
                  objectivity
                  > resides in recognizing your preferences and then subjecting them to
                  > especially harsh scrutiny — and also in a willingness to revise or
                  abandon
                  > your theories when the tests fail (as they usually do)."
                  > - Stephen Jay Gould
                  >
                  >
                  > [Non-text portions of this message have been removed]
                  >




                  [Non-text portions of this message have been removed]
                • Marco Dorantes
                  In an recent presentation, I heard the presenter emphatically referring to someone else code as `crap ; in the same presentation the presenter started to talk
                  Message 8 of 29 , Nov 9, 2007
                  • 0 Attachment
                    In an recent presentation, I heard the presenter emphatically
                    referring to someone else code as `crap'; in the same presentation
                    the presenter started to talk about architecture —and like most of
                    the conversations I have heard recently that include the architecture
                    concept— clearly implied that architecture is — above anything else—
                    about the structure (internal structure in particular) of the system.
                    In my research about the subject of architecture in other
                    professional design fields I have found that architecture is mainly
                    about usability and when those other professionals have seen what we
                    in the software industry know as architecture, they could
                    emphatically say `crap'.

                    --- In extremeprogramming@yahoogroups.com, "Matt Heusser"
                    <matt.heusser@...> wrote:
                    >
                    > My first exposure to XP was reading the "Extreme Programming:
                    Installed."
                    >
                    > I was struck and impressed in the whole team/consensus
                    based/emergent design
                    > ideal.
                    >
                    > Recently I've begun to hear more and more rumblings around the idea
                    of
                    > "Agile Architecture."
                    >
                    > I ask this in the XP list, because XP was well-established and did
                    not have
                    > a role for Architect at the snowbird conference in 2001 when the
                    Manifesto
                    > was penned:
                    >
                    > What does Agile Architecture mean? and how would it be done?
                    >
                    > (Feel free to answer something like "I don't know. Nobody else does
                    either.
                    > Have you read who needs an architect by Martin Fowler?" - I think
                    that could
                    > add to a lively discussion. :-)
                    >
                    > Regards,
                    >
                    > --
                    > Matthew Heusser,
                    > Blog: http://xndev.blogspot.com
                    >
                    > "Objectivity cannot be equated with mental blankness; rather,
                    objectivity
                    > resides in recognizing your preferences and then subjecting them to
                    > especially harsh scrutiny — and also in a willingness to revise or
                    abandon
                    > your theories when the tests fail (as they usually do)."
                    > - Stephen Jay Gould
                    >
                    >
                    > [Non-text portions of this message have been removed]
                    >
                  • John Roth
                    Well, maybe, maybe not. I m not sure who brought the terms architecture and architect into this field. I am sure one could make a case that it was based on a
                    Message 9 of 29 , Nov 9, 2007
                    • 0 Attachment
                      Well, maybe, maybe not. I'm not sure who brought
                      the terms architecture and architect into this field.
                      I am sure one could make a case that it was based
                      on a false analogy, or at least on insufficient knowledge
                      of how other fields are actually structured.

                      John Roth


                      ----- Original Message -----
                      From: "Marco Dorantes" <marcodorantes@...>
                      To: <extremeprogramming@yahoogroups.com>
                      Sent: Friday, November 09, 2007 8:24 AM
                      Subject: [XP] Re: Question about Architecture


                      In an recent presentation, I heard the presenter emphatically
                      referring to someone else code as `crap'; in the same presentation
                      the presenter started to talk about architecture -and like most of
                      the conversations I have heard recently that include the architecture
                      concept- clearly implied that architecture is - above anything else-
                      about the structure (internal structure in particular) of the system.
                      In my research about the subject of architecture in other
                      professional design fields I have found that architecture is mainly
                      about usability and when those other professionals have seen what we
                      in the software industry know as architecture, they could
                      emphatically say `crap'.

                      --- In extremeprogramming@yahoogroups.com, "Matt Heusser"
                      <matt.heusser@...> wrote:
                      >
                      > My first exposure to XP was reading the "Extreme Programming:
                      Installed."
                      >
                      > I was struck and impressed in the whole team/consensus
                      based/emergent design
                      > ideal.
                      >
                      > Recently I've begun to hear more and more rumblings around the idea
                      of
                      > "Agile Architecture."
                      >
                      > I ask this in the XP list, because XP was well-established and did
                      not have
                      > a role for Architect at the snowbird conference in 2001 when the
                      Manifesto
                      > was penned:
                      >
                      > What does Agile Architecture mean? and how would it be done?
                      >
                      > (Feel free to answer something like "I don't know. Nobody else does
                      either.
                      > Have you read who needs an architect by Martin Fowler?" - I think
                      that could
                      > add to a lively discussion. :-)
                      >
                      > Regards,
                      >
                      > --
                      > Matthew Heusser,
                      > Blog: http://xndev.blogspot.com
                      >
                      > "Objectivity cannot be equated with mental blankness; rather,
                      objectivity
                      > resides in recognizing your preferences and then subjecting them to
                      > especially harsh scrutiny - and also in a willingness to revise or
                      abandon
                      > your theories when the tests fail (as they usually do)."
                      > - Stephen Jay Gould
                      >
                      >
                      > [Non-text portions of this message have been removed]
                      >
                    • Scott Ambler
                      ... A common theme within the software architecture community is that you need to consider several views when communicating the architecture of a system.
                      Message 10 of 29 , Nov 10, 2007
                      • 0 Attachment
                        --- In extremeprogramming@yahoogroups.com, "Marco Dorantes"
                        <marcodorantes@...> wrote:
                        >
                        > In an recent presentation, I heard the presenter emphatically
                        > referring to someone else code as `crap'; in the same presentation
                        > the presenter started to talk about architecture —and like most of
                        > the conversations I have heard recently that include the architecture
                        > concept— clearly implied that architecture is — above anything else—
                        > about the structure (internal structure in particular) of the system.
                        > In my research about the subject of architecture in other
                        > professional design fields I have found that architecture is mainly
                        > about usability and when those other professionals have seen what we
                        > in the software industry know as architecture, they could
                        > emphatically say `crap'.

                        A common theme within the software architecture community is that you
                        need to consider several views when communicating the architecture of a
                        system. Although there are differing schemes as to which views should
                        be considered, invariably at least one of the views always seems to
                        address the structure of the system. But this is one, and often the
                        simplest, of views. Grady Booch is currently working on a handbook of
                        software architecture, see http://www.booch.com/architecture/index.jsp,
                        which may provide some interesting insights. The site includes many
                        reference architectures from reasonably well known systems from over
                        the years.

                        - Scott
                      • Marco Dorantes
                        Indeed, the 4+1 View Model of Software Architecture by Philippe Kruchten could be considered as a start —not an end— of our understanding of architecture
                        Message 11 of 29 , Nov 12, 2007
                        • 0 Attachment
                          Indeed, the "4+1" View Model of Software Architecture by Philippe
                          Kruchten could be considered as a start —not an end— of our
                          understanding of architecture in software. In that work, what gives
                          purpose to all the technical views is their connection with the "+1"
                          view: use cases. Therefore, further understanding of architecture in
                          our field goes on the usability path.

                          --- In extremeprogramming@yahoogroups.com, "Scott Ambler"
                          <scottwambler@...> wrote:
                          >
                          > --- In extremeprogramming@yahoogroups.com, "Marco Dorantes"
                          > <marcodorantes@> wrote:
                          > >
                          > > In an recent presentation, I heard the presenter emphatically
                          > > referring to someone else code as `crap'; in the same
                          presentation
                          > > the presenter started to talk about architecture —and like most
                          of
                          > > the conversations I have heard recently that include the
                          architecture
                          > > concept— clearly implied that architecture is — above anything
                          else—
                          > > about the structure (internal structure in particular) of the
                          system.
                          > > In my research about the subject of architecture in other
                          > > professional design fields I have found that architecture is
                          mainly
                          > > about usability and when those other professionals have seen what
                          we
                          > > in the software industry know as architecture, they could
                          > > emphatically say `crap'.
                          >
                          > A common theme within the software architecture community is that
                          you
                          > need to consider several views when communicating the architecture
                          of a
                          > system. Although there are differing schemes as to which views
                          should
                          > be considered, invariably at least one of the views always seems to
                          > address the structure of the system. But this is one, and often
                          the
                          > simplest, of views. Grady Booch is currently working on a handbook
                          of
                          > software architecture, see
                          http://www.booch.com/architecture/index.jsp,
                          > which may provide some interesting insights. The site includes many
                          > reference architectures from reasonably well known systems from
                          over
                          > the years.
                          >
                          > - Scott
                          >
                        • Kelly Anderson
                          ... I ve heard several detractors of late state that the emergent architecture that comes out of the TDD process is suboptimal. IMHO it s because they aren t
                          Message 12 of 29 , Nov 12, 2007
                          • 0 Attachment
                            On Nov 9, 2007 8:24 AM, Marco Dorantes <marcodorantes@...> wrote:
                            > In an recent presentation, I heard the presenter emphatically
                            > referring to someone else code as `crap'; in the same presentation
                            > the presenter started to talk about architecture —and like most of
                            > the conversations I have heard recently that include the architecture
                            > concept— clearly implied that architecture is — above anything else—
                            > about the structure (internal structure in particular) of the system.
                            > In my research about the subject of architecture in other
                            > professional design fields I have found that architecture is mainly
                            > about usability and when those other professionals have seen what we
                            > in the software industry know as architecture, they could
                            > emphatically say `crap'.

                            I've heard several detractors of late state that the emergent
                            architecture that comes out of the TDD process is suboptimal. IMHO
                            it's because they aren't taking the refactoring stage seriously
                            enough. Nevertheless, since many practitioners don't take refactoring
                            seriously until they've built up a serious technical debt, this is
                            something I suspect we'll hear more and more as TDD goes from the
                            domain of the hard core geek squad into the great unwashed masses of
                            undisciplined business programmers.

                            As more of a question, if everyone is supposed to do refactoring, is
                            there still a role for a lead architect in the XP world? Or does
                            everyone architect together. The latter seems like it might result in
                            a bit of a mess if there aren't agreed upon programming approaches and
                            standards. Do you have a lead architect in your Agile group?

                            -Kelly
                          • Ron Jeffries
                            Hello, Kelly. On Monday, November 12, 2007, at 12:47:39 PM, you ... Yes. It s hard to know what to say about things like this. The TDD practice is pretty
                            Message 13 of 29 , Nov 12, 2007
                            • 0 Attachment
                              Hello, Kelly. On Monday, November 12, 2007, at 12:47:39 PM, you
                              wrote:

                              > I've heard several detractors of late state that the emergent
                              > architecture that comes out of the TDD process is suboptimal. IMHO
                              > it's because they aren't taking the refactoring stage seriously
                              > enough. Nevertheless, since many practitioners don't take refactoring
                              > seriously until they've built up a serious technical debt, this is
                              > something I suspect we'll hear more and more as TDD goes from the
                              > domain of the hard core geek squad into the great unwashed masses of
                              > undisciplined business programmers.

                              Yes. It's hard to know what to say about things like this. The TDD
                              practice is pretty solidly defined as test, code, refactor, rinse,
                              repeat.

                              If you really do that, removing duplication and expressing design
                              ideas, it's hard to see how you'd get a bad design out of the deal.

                              And if you //don't// do that, it's hard to see how you could blame
                              TDD for the problem.

                              Most peculiar, Mama.

                              > As more of a question, if everyone is supposed to do refactoring, is
                              > there still a role for a lead architect in the XP world? Or does
                              > everyone architect together. The latter seems like it might result in
                              > a bit of a mess if there aren't agreed upon programming approaches and
                              > standards. Do you have a lead architect in your Agile group?

                              I think that named roles are of dubious value in XP or Agile
                              methods. That's not to say that there won't be leaders, it's just to
                              say that we probably don't know who they are, and that identifying
                              one person as Lead Something may suppress all the
                              something-leadership that others on the team might do.

                              I'd like to see the whole team participate in architectural work.
                              The ones who don't have much to say won't say much, and they'll
                              learn. The ones with questions will ask them, s\and the ones with
                              ideas will express them, strengthening the design.

                              Ron Jeffries
                              www.XProgramming.com
                              Those who believe complexity is elegant or required don't understand
                              the problem. -- John Streiff
                            • Rob Park
                              As more of a question, if everyone is supposed to do refactoring, is there still a role for a lead architect in the XP world? Or does everyone architect
                              Message 14 of 29 , Nov 12, 2007
                              • 0 Attachment
                                "As more of a question, if everyone is supposed to do refactoring, is
                                there still a role for a lead architect in the XP world? Or does
                                everyone architect together. The latter seems like it might result in
                                a bit of a mess if there aren't agreed upon programming approaches and
                                standards. Do you have a lead architect in your Agile group?"

                                I don't think there's really a place for a "Lead" perse, however I think
                                it's unrealistic to think all on the team will be involved or know what to
                                say in a major architectural discussion. So you may have a captain or
                                co-captians, but ultimately, it is still important that someone can make the
                                decision on what path to take. A good leader will truly evaluate and
                                utilize the whole team's opinions.

                                .rob.


                                [Non-text portions of this message have been removed]
                              • Chris Wheeler
                                ... That s why I love XP/Agile so much - try as I might, I could never understand all that 4+1 view stuff. Like, why isn t it called 5 views ? Is the +1 a
                                Message 15 of 29 , Nov 12, 2007
                                • 0 Attachment
                                  On Nov 12, 2007 11:06 AM, Marco Dorantes <marcodorantes@...> wrote:

                                  > Indeed, the "4+1" View Model of Software Architecture by Philippe
                                  > Kruchten could be considered as a start �not an end� of our
                                  > understanding of architecture in software. In that work, what gives
                                  > purpose to all the technical views is their connection with the "+1"
                                  > view: use cases. Therefore, further understanding of architecture in
                                  > our field goes on the usability path.
                                  >

                                  That's why I love XP/Agile so much - try as I might, I could never
                                  understand all that 4+1 view stuff. Like, why isn't it called '5 views'? Is
                                  the +1 a charge, like on an ion, or something?

                                  In seriousness, I've spent time doing that 4+1 stuff, and it's great for
                                  parading around a few meetings, but eventually it just gets shelved when the
                                  coding starts, and doesn't get updated when the coding ends.

                                  Chris.


                                  [Non-text portions of this message have been removed]
                                • J. B. Rainsberger
                                  ... You get what you measure. :) ... Low-level architecture. -- J. B. (Joe) Rainsberger :: http://www.jbrains.ca Your guide to software craftsmanship JUnit
                                  Message 16 of 29 , Nov 12, 2007
                                  • 0 Attachment
                                    Matt Heusser wrote:
                                    > J.B. Rainsberger wrote:
                                    >
                                    >> When I hear "architecture" I think "high-level design".
                                    >> On that basis, I can only imagine that "agile architecture"
                                    >> refers to letting even the high-level design evolve: not being
                                    >> afraid to continue refactoring when you start changing one
                                    >> of the five most important concepts in your code base.
                                    >
                                    > For once, I completely agree with J.B. Sweet.

                                    You get what you measure. :)

                                    > Now, that said: What's design?

                                    Low-level architecture.
                                    --
                                    J. B. (Joe) Rainsberger :: http://www.jbrains.ca
                                    Your guide to software craftsmanship
                                    JUnit Recipes: Practical Methods for Programmer Testing
                                    2005 Gordon Pask Award for contribution Agile Software Practice
                                  • Nguyen Phuc Hai
                                    This thread made me remember my previous experience when many software architectures just show the relationship among layers and that s all (logical view). It
                                    Message 17 of 29 , Nov 13, 2007
                                    • 0 Attachment
                                      This thread made me remember my previous experience when many software architectures just show the relationship among layers and that's all (logical view). It is no surprise when developers code without care about the architecture because it is generic and it can be re-used across projects. I do think Agile architecture does not make sense because in any situations, your architecture must be documented enough for coding ( to implementation view in 4+1 model: at least to package level and responsibility of key classes are documented as well). The difference between Agile and traditional architecture not about the level of architecture detail but Agile encourage architecture is designed enough for current needs that can be extensible in future not big up-front design.

                                      Regards,
                                      Hai
                                      http://www.haiphucnguyen.net/blog/

                                      ----- Original Message ----
                                      From: J. B. Rainsberger <jbrains762@...>
                                      To: extremeprogramming@yahoogroups.com
                                      Sent: Monday, November 12, 2007 10:22:20 PM
                                      Subject: Re: [XP] Re: Question about Architecture













                                      Matt Heusser wrote:

                                      > J.B. Rainsberger wrote:

                                      >

                                      >> When I hear "architecture" I think "high-level design".

                                      >> On that basis, I can only imagine that "agile architecture"

                                      >> refers to letting even the high-level design evolve: not being

                                      >> afraid to continue refactoring when you start changing one

                                      >> of the five most important concepts in your code base.

                                      >

                                      > For once, I completely agree with J.B. Sweet.



                                      You get what you measure. :)



                                      > Now, that said: What's design?



                                      Low-level architecture.

                                      --

                                      J. B. (Joe) Rainsberger :: http://www.jbrains ca

                                      Your guide to software craftsmanship

                                      JUnit Recipes: Practical Methods for Programmer Testing

                                      2005 Gordon Pask Award for contribution Agile Software Practice












                                      <!--

                                      #ygrp-mkp{
                                      border:1px solid #d8d8d8;font-family:Arial;margin:14px 0px;padding:0px 14px;}
                                      #ygrp-mkp hr{
                                      border:1px solid #d8d8d8;}
                                      #ygrp-mkp #hd{
                                      color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;margin:10px 0px;}
                                      #ygrp-mkp #ads{
                                      margin-bottom:10px;}
                                      #ygrp-mkp .ad{
                                      padding:0 0;}
                                      #ygrp-mkp .ad a{
                                      color:#0000ff;text-decoration:none;}
                                      -->



                                      <!--

                                      #ygrp-sponsor #ygrp-lc{
                                      font-family:Arial;}
                                      #ygrp-sponsor #ygrp-lc #hd{
                                      margin:10px 0px;font-weight:bold;font-size:78%;line-height:122%;}
                                      #ygrp-sponsor #ygrp-lc .ad{
                                      margin-bottom:10px;padding:0 0;}
                                      -->



                                      <!--

                                      #ygrp-mlmsg {font-size:13px;font-family:arial, helvetica, clean, sans-serif;}
                                      #ygrp-mlmsg table {font-size:inherit;font:100%;}
                                      #ygrp-mlmsg select, input, textarea {font:99% arial, helvetica, clean, sans-serif;}
                                      #ygrp-mlmsg pre, code {font:115% monospace;}
                                      #ygrp-mlmsg * {line-height:1.22em;}
                                      #ygrp-text{
                                      font-family:Georgia;
                                      }
                                      #ygrp-text p{
                                      margin:0 0 1em 0;}
                                      #ygrp-tpmsgs{
                                      font-family:Arial;
                                      clear:both;}
                                      #ygrp-vitnav{
                                      padding-top:10px;font-family:Verdana;font-size:77%;margin:0;}
                                      #ygrp-vitnav a{
                                      padding:0 1px;}
                                      #ygrp-actbar{
                                      clear:both;margin:25px 0;white-space:nowrap;color:#666;text-align:right;}
                                      #ygrp-actbar .left{
                                      float:left;white-space:nowrap;}
                                      .bld{font-weight:bold;}
                                      #ygrp-grft{
                                      font-family:Verdana;font-size:77%;padding:15px 0;}
                                      #ygrp-ft{
                                      font-family:verdana;font-size:77%;border-top:1px solid #666;
                                      padding:5px 0;
                                      }
                                      #ygrp-mlmsg #logo{
                                      padding-bottom:10px;}

                                      #ygrp-vital{
                                      background-color:#e0ecee;margin-bottom:20px;padding:2px 0 8px 8px;}
                                      #ygrp-vital #vithd{
                                      font-size:77%;font-family:Verdana;font-weight:bold;color:#333;text-transform:uppercase;}
                                      #ygrp-vital ul{
                                      padding:0;margin:2px 0;}
                                      #ygrp-vital ul li{
                                      list-style-type:none;clear:both;border:1px solid #e0ecee;
                                      }
                                      #ygrp-vital ul li .ct{
                                      font-weight:bold;color:#ff7900;float:right;width:2em;text-align:right;padding-right:.5em;}
                                      #ygrp-vital ul li .cat{
                                      font-weight:bold;}
                                      #ygrp-vital a{
                                      text-decoration:none;}

                                      #ygrp-vital a:hover{
                                      text-decoration:underline;}

                                      #ygrp-sponsor #hd{
                                      color:#999;font-size:77%;}
                                      #ygrp-sponsor #ov{
                                      padding:6px 13px;background-color:#e0ecee;margin-bottom:20px;}
                                      #ygrp-sponsor #ov ul{
                                      padding:0 0 0 8px;margin:0;}
                                      #ygrp-sponsor #ov li{
                                      list-style-type:square;padding:6px 0;font-size:77%;}
                                      #ygrp-sponsor #ov li a{
                                      text-decoration:none;font-size:130%;}
                                      #ygrp-sponsor #nc{
                                      background-color:#eee;margin-bottom:20px;padding:0 8px;}
                                      #ygrp-sponsor .ad{
                                      padding:8px 0;}
                                      #ygrp-sponsor .ad #hd1{
                                      font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%;}
                                      #ygrp-sponsor .ad a{
                                      text-decoration:none;}
                                      #ygrp-sponsor .ad a:hover{
                                      text-decoration:underline;}
                                      #ygrp-sponsor .ad p{
                                      margin:0;}
                                      o{font-size:0;}
                                      .MsoNormal{
                                      margin:0 0 0 0;}
                                      #ygrp-text tt{
                                      font-size:120%;}
                                      blockquote{margin:0 0 0 4px;}
                                      .replbq{margin:4;}
                                      -->








                                      ____________________________________________________________________________________
                                      Be a better sports nut! Let your teams follow you
                                      with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

                                      [Non-text portions of this message have been removed]
                                    • Adrian Howard
                                      On 12 Nov 2007, at 17:47, Kelly Anderson wrote: [snip] ... [snip] We don t. We do have folk then tend to be the go-to-guys for particular classes of problems,
                                      Message 18 of 29 , Nov 13, 2007
                                      • 0 Attachment
                                        On 12 Nov 2007, at 17:47, Kelly Anderson wrote:
                                        [snip]
                                        > As more of a question, if everyone is supposed to do refactoring, is
                                        > there still a role for a lead architect in the XP world? Or does
                                        > everyone architect together. The latter seems like it might result in
                                        > a bit of a mess if there aren't agreed upon programming approaches and
                                        > standards. Do you have a lead architect in your Agile group?
                                        [snip]

                                        We don't.

                                        We do have folk then tend to be the go-to-guys for particular classes
                                        of problems, but they don't get separate job titles and they're
                                        definitely not the lead for all aspects of the system. They also help
                                        everybody make the design decisions, rather than making them all
                                        themselves.

                                        Works well in my experience. Pairing and common code ownership seem
                                        to resolve the "bit of a mess" scenario :-)

                                        Cheers,

                                        Adrian
                                      • Steven Gordon
                                        ... Hai, Why would figuring out the appropriate architecture upfront and documenting it be any better than figuring it out at implementation time when more
                                        Message 19 of 29 , Nov 13, 2007
                                        • 0 Attachment
                                          On Nov 13, 2007 2:00 AM, Nguyen Phuc Hai <haiphucnguyen@...> wrote:
                                          >
                                          > This thread made me remember my previous experience when many software
                                          > architectures just show the relationship among layers and that's all
                                          > (logical view). It is no surprise when developers code without care about
                                          > the architecture because it is generic and it can be re-used across
                                          > projects. I do think Agile architecture does not make sense because in any
                                          > situations, your architecture must be documented enough for coding ( to
                                          > implementation view in 4+1 model: at least to package level and
                                          > responsibility of key classes are documented as well).

                                          Hai,

                                          Why would figuring out the appropriate architecture upfront and
                                          documenting it be any better than figuring it out at implementation
                                          time when more information is available? The only possible reason I
                                          can see would be because coders are too dumb to be architects and
                                          architects are too rare to be coding?

                                          Agile attacks this skills problem by immersing "coders", "architects"
                                          (as well as testers, analysts, dbas, etc.) into a single team that
                                          takes responsibility for iteratively doing all the development
                                          acitivites in an integrated and self-checking way. It eliminates
                                          miscommunication by documentation, catches errors much sooner, and
                                          increases the general skills of every specialist.

                                          Steve

                                          > The difference
                                          > between Agile and traditional architecture not about the level of
                                          > architecture detail but Agile encourage architecture is designed enough for
                                          > current needs that can be extensible in future not big up-front design.
                                          >
                                          > Regards,
                                          > Hai
                                          > http://www.haiphucnguyen.net/blog/
                                          >
                                          >
                                        • Chris Wheeler
                                          ... I totally agree with this - architecture *must* always be documented enough to start coding. Now, what is *enough*? My mind says that *enough* is enough
                                          Message 20 of 29 , Nov 13, 2007
                                          • 0 Attachment
                                            On Nov 13, 2007 4:00 AM, Nguyen Phuc Hai <haiphucnguyen@...> wrote:

                                            > because in any situations, your architecture must be documented enough
                                            > for coding ( to implementation view in 4+1 model: at least to package level
                                            > and responsibility of key classes are documented as well).


                                            I totally agree with this - architecture *must* always be documented enough
                                            to start coding. Now, what is *enough*? My mind says that *enough* is
                                            enough to satisfy the customer - so a story, a test, and some code written
                                            with the discipline of a samarai. Done proper, that covers all the fears of
                                            the future.



                                            > The difference between Agile and traditional architecture not about the
                                            > level of architecture detail but Agile encourage architecture is designed
                                            > enough for current needs that can be extensible in future not big up-front
                                            > design.


                                            Well, I've done it both ways, and the only thing 4+1 architecture ever gave
                                            me was a product that was overly-focused on architecture and poorly-focused
                                            on what the customer wanted to pay money for. Too many shops want to build a
                                            fabulous, extensible, pluggable architecture when what they really need is a
                                            really well-written piece of software that satisfies the needs of current
                                            customers.

                                            Build the future when it gets here - that should be the motto of most shops.

                                            Chris.


                                            [Non-text portions of this message have been removed]
                                          • Sean McMillan
                                            ... Design is an attribute of the code. Code either has a good design, or a poor one. People who talk about design separate from code are either A: Using it as
                                            Message 21 of 29 , Nov 13, 2007
                                            • 0 Attachment
                                              Matt Heusser wrote:
                                              > Now, that said: What's design?
                                              Design is an attribute of the code. Code either has a good design,
                                              or a poor one. People who talk about design separate from code are
                                              either A: Using it as shorthand for "Some ideas about what the design
                                              should be once we've coded it," or B: Fooling themselves.

                                              If design were a separate noun, it would be reasonable to have tools
                                              that create designs. But there aren't any of those that don't end up in
                                              code eventually. If design were a verb, then it would be possible to
                                              have design specialists who only did design. We saw how well that worked
                                              in the BDUF years.

                                              All that said, I realize that I'm taking an unusual position here.
                                              I'd love for people to poke holes in this. Perhaps there's a better
                                              mental framework for thinking about design -- if so, I'd love to know
                                              about it!

                                              --Sean
                                            • Marco Dorantes
                                              Kelly, Your concerns are important and I have no easy answer, part of the answer that works is a team with people that care about what they are doing, and
                                              Message 22 of 29 , Nov 13, 2007
                                              • 0 Attachment
                                                Kelly,

                                                Your concerns are important and I have no easy answer, part of the
                                                answer that works is a team with people that care about what they are
                                                doing, and learn from each other as no one has all the answers. This
                                                other post in my blog points to some traits of members on a functional
                                                team and their talent:

                                                What type of person should design software?
                                                <http://blogs.msdn.com/marcod/archive/2007/02/17/SoftwareDesignersProfil\
                                                e.aspx>

                                                Regards.


                                                --- In extremeprogramming@yahoogroups.com, "Kelly Anderson"
                                                <kellycoinguy@...> wrote:
                                                >
                                                > On Nov 9, 2007 8:24 AM, Marco Dorantes marcodorantes@... wrote:
                                                > > In an recent presentation, I heard the presenter emphatically
                                                > > referring to someone else code as `crap'; in the same presentation
                                                > > the presenter started to talk about architecture —and like most
                                                of
                                                > > the conversations I have heard recently that include the
                                                architecture
                                                > > concept— clearly implied that architecture is — above
                                                anything else—
                                                > > about the structure (internal structure in particular) of the
                                                system.
                                                > > In my research about the subject of architecture in other
                                                > > professional design fields I have found that architecture is mainly
                                                > > about usability and when those other professionals have seen what we
                                                > > in the software industry know as architecture, they could
                                                > > emphatically say `crap'.
                                                >
                                                > I've heard several detractors of late state that the emergent
                                                > architecture that comes out of the TDD process is suboptimal. IMHO
                                                > it's because they aren't taking the refactoring stage seriously
                                                > enough. Nevertheless, since many practitioners don't take refactoring
                                                > seriously until they've built up a serious technical debt, this is
                                                > something I suspect we'll hear more and more as TDD goes from the
                                                > domain of the hard core geek squad into the great unwashed masses of
                                                > undisciplined business programmers.
                                                >
                                                > As more of a question, if everyone is supposed to do refactoring, is
                                                > there still a role for a lead architect in the XP world? Or does
                                                > everyone architect together. The latter seems like it might result in
                                                > a bit of a mess if there aren't agreed upon programming approaches and
                                                > standards. Do you have a lead architect in your Agile group?
                                                >
                                                > -Kelly
                                                >




                                                [Non-text portions of this message have been removed]
                                              • marty.nelson
                                                ... It s funny how in these discussions about architecture and design we talk about how red/green/refactor replaces BUFD, but no-one every mentions Shared
                                                Message 23 of 29 , Nov 13, 2007
                                                • 0 Attachment
                                                  --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                                                  <ronjeffries@...> wrote:
                                                  > The TDD
                                                  > practice is pretty solidly defined as test, code, refactor, rinse,
                                                  > repeat.
                                                  >
                                                  > If you really do that, removing duplication and expressing design
                                                  > ideas, it's hard to see how you'd get a bad design out of the deal.
                                                  >
                                                  > And if you //don't// do that, it's hard to see how you could blame
                                                  > TDD for the problem.
                                                  >
                                                  > Most peculiar, Mama.

                                                  It's funny how in these discussions about architecture and design we
                                                  talk about how red/green/refactor replaces BUFD, but no-one every
                                                  mentions Shared System Metaphor (there I just did). For the most
                                                  part, I'm in the camp that believes the code *is* the design. But
                                                  for that intangible, etherly, je ne sait qua'ness I'll call
                                                  cohesiveness, I always look for how well team members can communicate
                                                  about the components and interactions in the code.

                                                  I've often been in the midst of a conversation where just talking
                                                  about the design seems akward and the light bulb goes on and I
                                                  say "we need a better system metaphore for this part of the code."

                                                  - Marty
                                                • Marco Dorantes
                                                  Sean, I have looked at the properties of the medium to convey designs in other professional design disciplines and its properties, my finding so far is that
                                                  Message 24 of 29 , Nov 13, 2007
                                                  • 0 Attachment
                                                    Sean,

                                                    I have looked at the properties of the medium to convey designs in other
                                                    professional design disciplines and its properties, my finding so far
                                                    is that many in our industry -like you- already know that those
                                                    properties can only be found in the concept we know as "source code"
                                                    (which is in itself a technical document, to be understood by humans and
                                                    machines).

                                                    See more on:

                                                    Unconscious design defined
                                                    <http://blogs.msdn.com/marcod/archive/2005/04/03/UnconsciousDesignDefine\
                                                    d.aspx>

                                                    And also this:

                                                    An embryonic profession: Incomplete and unconscious design work
                                                    <http://blogs.msdn.com/marcod/archive/2006/05/04/AbstractionRole.aspx>

                                                    Regards.


                                                    --- In extremeprogramming@yahoogroups.com, Sean McMillan <reaper@...>
                                                    wrote:
                                                    >
                                                    > Matt Heusser wrote:
                                                    > > Now, that said: What's design?
                                                    > Design is an attribute of the code. Code either has a good design,
                                                    > or a poor one. People who talk about design separate from code are
                                                    > either A: Using it as shorthand for "Some ideas about what the design
                                                    > should be once we've coded it," or B: Fooling themselves.
                                                    >
                                                    > If design were a separate noun, it would be reasonable to have tools
                                                    > that create designs. But there aren't any of those that don't end up
                                                    in
                                                    > code eventually. If design were a verb, then it would be possible to
                                                    > have design specialists who only did design. We saw how well that
                                                    worked
                                                    > in the BDUF years.
                                                    >
                                                    > All that said, I realize that I'm taking an unusual position here.
                                                    > I'd love for people to poke holes in this. Perhaps there's a better
                                                    > mental framework for thinking about design -- if so, I'd love to know
                                                    > about it!
                                                    >
                                                    > --Sean
                                                    >




                                                    [Non-text portions of this message have been removed]
                                                  • Charlie Poole
                                                    Hi Marty, ... Bravo! I ve always said that the design is something in the mind of the designer/developer. It is expressed in the final product (code) and can
                                                    Message 25 of 29 , Nov 13, 2007
                                                    • 0 Attachment
                                                      Hi Marty,

                                                      > It's funny how in these discussions about architecture and
                                                      > design we talk about how red/green/refactor replaces BUFD,
                                                      > but no-one every mentions Shared System Metaphor (there I
                                                      > just did). For the most part, I'm in the camp that believes
                                                      > the code *is* the design. But for that intangible, etherly,
                                                      > je ne sait qua'ness I'll call cohesiveness, I always look for
                                                      > how well team members can communicate about the components
                                                      > and interactions in the code.

                                                      Bravo! I've always said that the design is something in the
                                                      mind of the designer/developer. It is expressed in the final
                                                      product (code) and can also be communicated to others on the
                                                      team in various ways - sketches on whiteboards, conversations,
                                                      short code examples, and (I suppose) UML diagrams.

                                                      The purpose of all this stuff is that the view of what we
                                                      are doing (design) in my brain should match that in yours.
                                                      Like many good things, it can be overdone, leading to
                                                      various forms of waste motion and piles of documentation.

                                                      > I've often been in the midst of a conversation where just
                                                      > talking about the design seems akward and the light bulb goes
                                                      > on and I say "we need a better system metaphore for this part
                                                      > of the code."

                                                      Metaphor, where you can find one, is the most efficient
                                                      communicator of design intent we have found. Unfortunately,
                                                      calling it Metaphor didn't communicate very well to many
                                                      people. Kent said somewhere - I think in his OOPSLA talk
                                                      on "Tropes" - that "Metaphor" may have been a bad metaphor
                                                      for what he was trying to say, but I keep using it. At
                                                      least I use it in my head, sometimes translating it into
                                                      other terms for the audience at hand.

                                                      Charlie

                                                      > - Marty
                                                      >
                                                      >
                                                      >
                                                      > To Post a message, send it to: extremeprogramming@...
                                                      >
                                                      > To Unsubscribe, send a blank message to:
                                                      > extremeprogramming-unsubscribe@...
                                                      >
                                                      > ad-free courtesy of objectmentor.com
                                                      > Yahoo! Groups Links
                                                      >
                                                      >
                                                      >
                                                      >
                                                    • Ray Tayek
                                                      ... i think its a *different* kind of view: rumbaugh says A view is simply a subset of UML modeling constructs that represent on aspect of a system. in the
                                                      Message 26 of 29 , Nov 13, 2007
                                                      • 0 Attachment
                                                        At 08:41 PM 11/12/2007, you wrote:
                                                        >On Nov 12, 2007 11:06 AM, Marco Dorantes <marcodorantes@...> wrote:
                                                        >
                                                        > > Indeed, the "4+1" View Model of Software Architecture by Philippe
                                                        > > Kruchten could be considered as a start —not an end— of our
                                                        > > understanding of architecture in software. In that work, what gives
                                                        > > purpose to all the technical views is their connection with the "+1"
                                                        > > view: use cases. Therefore, further understanding of architecture in
                                                        > > our field goes on the usability path.
                                                        > >
                                                        >
                                                        >That's why I love XP/Agile so much - try as I might, I could never
                                                        >understand all that 4+1 view stuff. Like, why isn't it called '5 views'? Is
                                                        >the +1 a charge, like on an ion, or something?

                                                        i think its a *different* kind of view:

                                                        rumbaugh says "A view is simply a subset of UML
                                                        modeling constructs that represent on aspect of a
                                                        system." in the uml reference manual." in
                                                        http://www.amazon.com/Modeling-Language-Reference-Addison-Wesley-Technology/dp/020130998X.
                                                        rumbaugh lists 9 or so views.

                                                        booch says " ... Each view is a projection into
                                                        the organization and structure of the system,
                                                        focused on a particular aspect of that system."
                                                        and " ... The use case view of a system
                                                        encompasses the use cases that describe the
                                                        behavior of the system as seen by its end users,
                                                        analysts, and testers. This view doesn't really
                                                        specify the organization of a software system.
                                                        Rather it exists to specify the forces that shape
                                                        the system's architecture. ... " in
                                                        http://www.amazon.com/Unified-Modeling-Language-User-Guide/dp/0201571684
                                                        (first edition). booch claims "... the
                                                        architecture of a software intensive system can
                                                        best be described by five interlocking views. Each view is a projection ..."

                                                        iirc, this 4+1 diagram was popularized by fowler in his uml distilled series?

                                                        thanks

                                                        ---
                                                        vice-chair http://ocjug.org/
                                                      • Cory Foy
                                                        ... I think this is perhaps the best metaphor for architects. For a Soccer team, you have a captain, but he doesn t sit in the booth looking over the field,
                                                        Message 27 of 29 , Nov 13, 2007
                                                        • 0 Attachment
                                                          Rob Park wrote:
                                                          > I don't think there's really a place for a "Lead" perse, however I think
                                                          > it's unrealistic to think all on the team will be involved or know what to
                                                          > say in a major architectural discussion. So you may have a captain or
                                                          > co-captians, but ultimately, it is still important that someone can make the
                                                          > decision on what path to take. A good leader will truly evaluate and
                                                          > utilize the whole team's opinions.

                                                          I think this is perhaps the best metaphor for architects. For a Soccer
                                                          team, you have a captain, but he doesn't sit in the booth looking over
                                                          the field, making calls. He's on the field, an active participant in the
                                                          game, but also watching everything else that is going on. Having a good
                                                          captain can a good team make, but having a crappy goalie will still cost
                                                          you the game. ;)

                                                          --
                                                          Cory Foy
                                                          http://www.cornetdesign.com
                                                        • Chris Wheeler
                                                          Wow! That sounds way more complicated than what I ve been doing in Agile, and I m getting some pretty decent results. I was being a bit of a git when I posted
                                                          Message 28 of 29 , Nov 13, 2007
                                                          • 0 Attachment
                                                            Wow! That sounds way more complicated than what I've been doing in Agile,
                                                            and I'm getting some pretty decent results. I was being a bit of a git when
                                                            I posted this, as I've done 4+1... A question: does anyone here who uses 4+1
                                                            *use* the artifacts a year or so later?

                                                            And a challenge I wish I could setup: I'll take 4 programmers and 1
                                                            customer. Another team take an architect and 5 other people. From go, we
                                                            both have to implement a substantial piece of software within 3 months. I
                                                            use agile, they use 4+1. Then, put it all away for a month. Come back, same
                                                            architect, and me, except we have to bring different team mates. Now, we
                                                            implement 4 new features and it has to be done in 2 weeks.

                                                            Winner is rated on customer satisfaction, first to market and defects found
                                                            after the 2 week period.

                                                            Challenge is a little vague (close to bedtime), but I'd bet on my team every
                                                            time.

                                                            Chris.

                                                            On Nov 13, 2007 6:16 PM, Ray Tayek <rtayek@...> wrote:

                                                            > At 08:41 PM 11/12/2007, you wrote:
                                                            > >On Nov 12, 2007 11:06 AM, Marco Dorantes <marcodorantes@...>
                                                            > wrote:
                                                            > >
                                                            > > > Indeed, the "4+1" View Model of Software Architecture by Philippe
                                                            > > > Kruchten could be considered as a start �not an end� of our
                                                            > > > understanding of architecture in software. In that work, what gives
                                                            > > > purpose to all the technical views is their connection with the "+1"
                                                            > > > view: use cases. Therefore, further understanding of architecture in
                                                            > > > our field goes on the usability path.
                                                            > > >
                                                            > >
                                                            > >That's why I love XP/Agile so much - try as I might, I could never
                                                            > >understand all that 4+1 view stuff. Like, why isn't it called '5 views'?
                                                            > Is
                                                            > >the +1 a charge, like on an ion, or something?
                                                            >
                                                            > i think its a *different* kind of view:
                                                            >
                                                            > rumbaugh says "A view is simply a subset of UML
                                                            > modeling constructs that represent on aspect of a
                                                            > system." in the uml reference manual." in
                                                            >
                                                            > http://www.amazon.com/Modeling-Language-Reference-Addison-Wesley-Technology/dp/020130998X
                                                            > .
                                                            > rumbaugh lists 9 or so views.
                                                            >
                                                            > booch says " ... Each view is a projection into
                                                            > the organization and structure of the system,
                                                            > focused on a particular aspect of that system."
                                                            > and " ... The use case view of a system
                                                            > encompasses the use cases that describe the
                                                            > behavior of the system as seen by its end users,
                                                            > analysts, and testers. This view doesn't really
                                                            > specify the organization of a software system.
                                                            > Rather it exists to specify the forces that shape
                                                            > the system's architecture. ... " in
                                                            > http://www.amazon.com/Unified-Modeling-Language-User-Guide/dp/0201571684
                                                            > (first edition). booch claims "... the
                                                            > architecture of a software intensive system can
                                                            > best be described by five interlocking views. Each view is a projection
                                                            > ..."
                                                            >
                                                            > iirc, this 4+1 diagram was popularized by fowler in his uml distilled
                                                            > series?
                                                            >
                                                            > thanks
                                                            >
                                                            > ---
                                                            > vice-chair http://ocjug.org/
                                                            >
                                                            >
                                                            >
                                                            >
                                                            > To Post a message, send it to: extremeprogramming@...
                                                            >
                                                            > To Unsubscribe, send a blank message to:
                                                            > extremeprogramming-unsubscribe@...
                                                            >
                                                            > ad-free courtesy of objectmentor.com
                                                            > Yahoo! Groups Links
                                                            >
                                                            >
                                                            >
                                                            >


                                                            [Non-text portions of this message have been removed]
                                                          • George Dinwiddie
                                                            ... Excellent, Marty! While the metaphor concept doesn t seem to work for everyone, it s clear that code that holds together well is due to a shared
                                                            Message 29 of 29 , Nov 13, 2007
                                                            • 0 Attachment
                                                              marty.nelson wrote:
                                                              > It's funny how in these discussions about architecture and design we
                                                              > talk about how red/green/refactor replaces BUFD, but no-one every
                                                              > mentions Shared System Metaphor (there I just did). For the most
                                                              > part, I'm in the camp that believes the code *is* the design. But
                                                              > for that intangible, etherly, je ne sait qua'ness I'll call
                                                              > cohesiveness, I always look for how well team members can communicate
                                                              > about the components and interactions in the code.
                                                              >
                                                              > I've often been in the midst of a conversation where just talking
                                                              > about the design seems akward and the light bulb goes on and I
                                                              > say "we need a better system metaphore for this part of the code."

                                                              Excellent, Marty! While the metaphor concept doesn't seem to work for
                                                              everyone, it's clear that code that holds together well is due to a
                                                              shared understanding of how the system fits together. That could well
                                                              be from reading an architectural design document--it's just that I've
                                                              never seen that stick in people's minds. And they don't refer back to
                                                              that document when their fingers are on the keyboard.

                                                              A metaphor, even a "naive" one based on the problem domain, is
                                                              incredibly powerful in helping humans hold complex designs in their
                                                              minds. And that makes all the difference in the world.

                                                              - George

                                                              --
                                                              ----------------------------------------------------------------------
                                                              * George Dinwiddie * http://blog.gdinwiddie.com
                                                              Software Development http://www.idiacomputing.com
                                                              Consultant and Coach http://www.agilemaryland.org
                                                              ----------------------------------------------------------------------
                                                            Your message has been successfully submitted and would be delivered to recipients shortly.