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

System Design in XP... what are your results?

Expand Messages
  • James Carr
    Hi All, Today I attended an interesting essay at OOPSLA 06 on System Design, and the presenter discussed some interesting points on XP (and open source). He
    Message 1 of 14 , Oct 25, 2006
      Hi All,

      Today I attended an interesting essay at OOPSLA '06 on System Design,
      and the presenter discussed some interesting points on XP (and open
      source). He stated that XP somehow maintains the illusion that there
      is little or no design, yet the communication between pairs is what
      the meat of how system design gets done.

      However, one member of the audience brought up that they have observed
      that many times the design that is done in XP is influenced by the
      pressure of "making the date" (I know this is really a management
      thing, but it is a pressure that developers sometimes feel netherless)
      and as a result sometimes the design is simple, yet only focuses on
      solving the task at hand, and as a result when the system grows
      larger, sometimes the design is a patched together small designs and
      doesn't really fit coherently.

      I thought this would be an interesting topic to discuss as I feel it
      is a common symptom not of XP, but developers who are attempting to
      integrate XP. What do you think about this observation? What have you
      observered, what were the challanges, and how did you solve the design
      issues you faced (if any)?

      Thanks,
      James
    • George Dinwiddie
      ... I think this is a common symptom of development teams, even those who ostensibly are doing the design up front. Some people generalize well, and some
      Message 2 of 14 , Oct 26, 2006
        James Carr wrote:
        > However, one member of the audience brought up that they have observed
        > that many times the design that is done in XP is influenced by the
        > pressure of "making the date" (I know this is really a management
        > thing, but it is a pressure that developers sometimes feel netherless)
        > and as a result sometimes the design is simple, yet only focuses on
        > solving the task at hand, and as a result when the system grows
        > larger, sometimes the design is a patched together small designs and
        > doesn't really fit coherently.

        I think this is a common symptom of development teams, even those who
        ostensibly are doing the design up front. Some people generalize well,
        and some don't, for whatever reason. Even when an organizing pattern
        (such as MVC or three-tier) is ostensibly used, I've often seen the code
        subvert that pattern in short-sighted ways.

        The promise of architect-driven development is that you only have to
        have one person, the system architect, understand design. I've not seen
        this play out well. The promise of XP is that the team will grow the
        design together. As you point out, the team still has to spend some
        time focusing on the big picture, and have the skills to do so, in order
        for this to work well. A team driven by schedule pressure to the point
        they have no slack for reflection will not do a good job at this,
        because it undermines the feedback.

        - George


        --
        ----------------------------------------------------------------------
        * George Dinwiddie * gdinwiddie@...
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Ilja Preuss
        ... I feel it s a common symptom of software development. Even with big design upfront, there will come a lot of changes later in the process, and when there
        Message 3 of 14 , Oct 28, 2006
          James Carr schrieb:

          > However, one member of the audience brought up that they have observed
          > that many times the design that is done in XP is influenced by the
          > pressure of "making the date" (I know this is really a management
          > thing, but it is a pressure that developers sometimes feel netherless)
          > and as a result sometimes the design is simple, yet only focuses on
          > solving the task at hand, and as a result when the system grows
          > larger, sometimes the design is a patched together small designs and
          > doesn't really fit coherently.
          >
          > I thought this would be an interesting topic to discuss as I feel it
          > is a common symptom not of XP, but developers who are attempting to
          > integrate XP.

          I feel it's a common symptom of software development. Even with big
          design upfront, there will come a lot of changes later in the process,
          and when there is enough pressure, they will be patched on the existing
          system.

          If at all, XP (or other Agile) teams will be in a *better* position to
          deal with it, because they are used to design while coding, and because
          they have experience with transforming inadequate designs to better ones
          through refactoring.

          Just my 0.02,

          Ilja
        • James Carr
          Hi Ilja, thanks for your response. ... I agree... which is why I am crious on the how part. Although the team should always be refactoring and evolving the
          Message 4 of 14 , Oct 28, 2006
            Hi Ilja, thanks for your response.

            On 10/28/06, Ilja Preuss <it@...> wrote:

            > If at all, XP (or other Agile) teams will be in a *better* position to
            > deal with it, because they are used to design while coding, and because
            > they have experience with transforming inadequate designs to better ones
            > through refactoring.
            >







            I agree... which is why I am crious on the "how" part. Although the team
            should always be refactoring and evolving the design, there can be times
            where the design gets out of control.

            Perhaps every so often the team should submit a card into the iteration to
            set time aside to perhaps do a small review of their system design and
            identify areas of improvement and act on those areas to ensure well done
            simple design.


            Thanks,
            James


            [Non-text portions of this message have been removed]
          • Bill Caputo
            ... I believe that is what slack is for. I feel that professional programmers have a natural desire to improve their systems if they aren t constantly being
            Message 5 of 14 , Oct 28, 2006
              On 10/28/06, James Carr <james.r.carr@...> wrote:
              > > If at all, XP (or other Agile) teams will be in a *better* position to
              > > deal with it, because they are used to design while coding, and because
              > > they have experience with transforming inadequate designs to better ones
              > > through refactoring.
              > >
              >
              > I agree... which is why I am crious on the "how" part. Although the team
              > should always be refactoring and evolving the design, there can be times
              > where the design gets out of control.

              I believe that is what slack is for. I feel that professional
              programmers have a natural desire to improve their systems if they
              aren't constantly being directed in where to focus their energy (i.e.
              stories and tasks).

              We have been looking for ways to integrate slack into our process for
              some time -- with less success than I like. Setting aside time in
              weekly (or larger) increments hasn't worked well. So we are now trying
              to do this by breaking the day into 2 task-oriented sessions of
              approximately 3 hours (i.e. 2/3 instead of 4/2 or 2/4). We are
              encouraging the team to wind down around task-oriented work around
              3:00 (but leaving it up to them), and turn their attention for the
              rest of the day toward aspects of the system (past, present or future)
              that interest them.

              The goal is to build-in highly collaborative (i.e. not people just
              sitting at their laptops surfing the web), and relevant (i.e. work
              related to our system) time that isn't driven by stories and tasks.

              We (being management) are committed to the idea that even if velocity
              initially drops with this arrangement, the long-term velocity,
              quality, and satisfaction benefits that we expect will more than
              compensate. Its important that we don't talk out both sides of our
              mouth, and uwittingly place pressure to go faster.

              So far, I like what I've seen. The team is already using this time to
              address design issues and other long-standing itches that haven't
              found their way to being addressed in the course of story work,
              investigate new technologies and to delve into areas of the code that
              they don't personally understand well.

              Best,
              Bill
            • Ilja Preuss
              ... Well, before we can fix that, we need to know why it happens... Does the team have iteration retrospectives? Do they discuss what happened when the design
              Message 6 of 14 , Oct 28, 2006
                James Carr schrieb:
                > Although the team
                > should always be refactoring and evolving the design, there can be times
                > where the design gets out of control.

                Well, before we can fix that, we need to know why it happens...

                Does the team have iteration retrospectives? Do they discuss what
                happened when the design got out of control?


                > Perhaps every so often the team should submit a card into the iteration to
                > set time aside to perhaps do a small review of their system design and
                > identify areas of improvement and act on those areas to ensure well done
                > simple design.

                Could work, but I'm actually not in favor of deferring it even that long.

                What if we made that part of every story? That is, at the end of every
                story, have those having worked on it reflect on how it affected the
                system design.

                Curious, Ilja
              • Ron Jeffries
                Hello, Bill. On Saturday, October 28, 2006, at 12:36:26 PM, you ... Good stuff, Bill. Thanks! Ron Jeffries www.XProgramming.com My advice is to do it by the
                Message 7 of 14 , Oct 28, 2006
                  Hello, Bill. On Saturday, October 28, 2006, at 12:36:26 PM, you
                  wrote:

                  > We (being management) are committed to the idea that even if velocity
                  > initially drops with this arrangement, the long-term velocity,
                  > quality, and satisfaction benefits that we expect will more than
                  > compensate. Its important that we don't talk out both sides of our
                  > mouth, and uwittingly place pressure to go faster.

                  Good stuff, Bill. Thanks!

                  Ron Jeffries
                  www.XProgramming.com
                  My advice is to do it by the book, get good at the practices, then do as
                  you will. Many people want to skip to step three. How do they know?
                • George Dinwiddie
                  ... I think that the team should continuously review their system design, and when the big picture starts seeming fuzzy, any team member can step up to the
                  Message 8 of 14 , Oct 29, 2006
                    James Carr wrote:
                    > Perhaps every so often the team should submit a card into the iteration to
                    > set time aside to perhaps do a small review of their system design and
                    > identify areas of improvement and act on those areas to ensure well done
                    > simple design.

                    I think that the team should continuously review their system design,
                    and when the big picture starts seeming fuzzy, any team member can step
                    up to the whiteboard and start a small discussion about how and why it
                    seems fuzzy. I find it best that the big picture reside within the head
                    of each team member, who can sketch it whenever needed or sketch
                    portions of the design in more detail to discuss it. If team members
                    find this difficult, leaving a diagram on the whiteboard for reference,
                    discussion and modification can be a simple and useful technique.

                    - George


                    --
                    ----------------------------------------------------------------------
                    * George Dinwiddie * gdinwiddie@...
                    Software Development http://www.idiacomputing.com
                    Consultant and Coach http://www.agilemaryland.org
                    ----------------------------------------------------------------------
                  • Gary Brown
                    ... A design ends up in a particular place because of the choices we make. We will never have perfect knowledge of what is needed or how to do it. We can only
                    Message 9 of 14 , Oct 29, 2006
                      Quoting James Carr <james.r.carr@...>:

                      > Hi Ilja, thanks for your response.
                      >
                      > On 10/28/06, Ilja Preuss <it@...> wrote:
                      >
                      >> If at all, XP (or other Agile) teams will be in a *better* position to
                      >> deal with it, because they are used to design while coding, and because
                      >> they have experience with transforming inadequate designs to better ones
                      >> through refactoring.
                      >>
                      > I agree... which is why I am crious on the "how" part. Although the team
                      > should always be refactoring and evolving the design, there can be times
                      > where the design gets out of control.

                      A design ends up in a particular place because of the choices we make.
                      We will never have perfect knowledge of what is needed or how to do
                      it. We can only do our best. The question is will we do our best, or
                      will we settle for something less?

                      I think that simple design, test-driven development, and merciless
                      refactoring give us the means and the responsibility to continuously
                      improve our designs. Too often, we choose to allow duplication,
                      harmful dependencies, and unneeded complexity, to remain, because we
                      believe that we don't have time to correct them now. Each time we
                      make that choice, we settle for lower quality now and slower delivery
                      in the future.

                      The only way to learn how much refactoring is just enough for now, is
                      to do it. Sometimes we'll do too much and miss our deadline.
                      Sometimes we'll do too little and get no benefit. Sometimes we'll get
                      it just right and our task will be done sooner than expected.

                      >
                      > Perhaps every so often the team should submit a card into the iteration to
                      > set time aside to perhaps do a small review of their system design and
                      > identify areas of improvement and act on those areas to ensure well done
                      > simple design.

                      I'd like to think that we could review and improve our designs within
                      the context of doing the work. If velocity is truly a measure of how
                      much value a team can deliver in a given amount of time, then
                      reviewing and improving our designs must be part of it. I think that
                      if we need to add a story to remind ourselves to do quality work, then
                      we have wandered way off course.

                      GB.
                    • Brad Appleton
                      I like what Feature-Driven Development (FDD) does here ... FDD explicitly maintains a domain (object) model. That model is created in a very collaborative
                      Message 10 of 14 , Oct 31, 2006
                        I like what Feature-Driven Development (FDD) does here ... FDD
                        explicitly maintains a domain (object) model. That model is created in a
                        very collaborative fashion (not just pairing, team-wide).

                        As written, FDD employs a "chief" architect, and "chief programmers"
                        from each feature-team. This implies a multi-team model with an almost
                        "technical scrum of scrums" for the domain-model. However I dont see why
                        a similar type of collaborative lightweight domain-modeling approach
                        couldnt also be used for a single small team.

                        I think Scott Ambler's "Agile Modeling" sort of does this, but perhaps a
                        bit less formal than FDD. I think it's possible to reach a happy medium
                        between the two, without the model becoming too detailed or too much
                        BDUF (but it sure would be easy/tempting to fall into traps along either
                        of those issues)


                        --
                        Brad Appleton <brad {AT} bradapp.net>
                        Agile CM Environments (http://blog.bradapp.net/)
                        & Software CM Patterns (www.scmpatterns.com)
                        "And miles to go before I sleep" -- Robert Frost
                      • J. B. Rainsberger
                        ... I have noticed a particular pattern in my current practice. When designing with someone on the team I m coaching, we test-drive some code, then come to a
                        Message 11 of 14 , Nov 2, 2006
                          James Carr wrote:

                          > However, one member of the audience brought up that they have observed
                          > that many times the design that is done in XP is influenced by the
                          > pressure of "making the date" (I know this is really a management
                          > thing, but it is a pressure that developers sometimes feel netherless)
                          > and as a result sometimes the design is simple, yet only focuses on
                          > solving the task at hand, and as a result when the system grows
                          > larger, sometimes the design is a patched together small designs and
                          > doesn't really fit coherently.
                          >
                          > I thought this would be an interesting topic to discuss as I feel it
                          > is a common symptom not of XP, but developers who are attempting to
                          > integrate XP. What do you think about this observation? What have you
                          > observered, what were the challanges, and how did you solve the design
                          > issues you faced (if any)?

                          I have noticed a particular pattern in my current practice. When
                          designing with someone on the team I'm coaching, we test-drive some
                          code, then come to a point where we need to touch what's there. When we
                          refactor, I do this little thing here, then inline this, then do this
                          little bit here.... then about 10 minutes later, I harrumph. We notice
                          that, in order to take the next step, the problem we face is invariably
                          either "To take the next stepp, we have to (do XYZ) in about 12
                          different places" or "The next change ripples to there, then there, then
                          there... oy, that's a long way!"

                          Those two are the biggest symptoms of bad design I come across, and they
                          are definitely influenced heavily by programmers buckling under when the
                          pressure is on. Some of it is skill, but I think that's actually easy to
                          learn--it just might not be comfortable to practice on the job.

                          Take care.
                          --
                          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
                        • Chris Wheeler
                          ... Jim Shore taught me that any one on the team should be able to describe the system design in about 10 minutes, with a few critical boxes and lines. This is
                          Message 12 of 14 , Nov 3, 2006
                            >
                            >
                            > I have noticed a particular pattern in my current practice. When
                            > designing with someone on the team I'm coaching, we test-drive some
                            > code, then come to a point where we need to touch what's there. When we
                            > refactor, I do this little thing here, then inline this, then do this
                            > little bit here.... then about 10 minutes later, I harrumph. We notice
                            > that, in order to take the next step, the problem we face is invariably
                            > either "To take the next stepp, we have to (do XYZ) in about 12
                            > different places" or "The next change ripples to there, then there, then
                            > there... oy, that's a long way!"
                            >

                            Jim Shore taught me that any one on the team should be able to describe the
                            system design in about 10 minutes, with a few critical boxes and lines. This
                            is hard to do if one isn't used to it. To get our teams used to this
                            concept, we do what are called 'design etudes' which let the team practice
                            this new concept.

                            Once the team is used to doing this, design sessions around the 'big'
                            refactorings, changes, etc, can take place quickly and directions can be
                            decided on before coding.

                            Chris.


                            [Non-text portions of this message have been removed]
                          • Nick Robinson
                            ________________________________ From: extremeprogramming@yahoogroups.com on behalf of James Carr Sent: Thu 26/10/2006 7:12 AM To:
                            Message 13 of 14 , Nov 10, 2006
                              ________________________________

                              From: extremeprogramming@yahoogroups.com on behalf of James Carr
                              Sent: Thu 26/10/2006 7:12 AM
                              To: extremeprogramming@yahoogroups.com
                              Subject: [XP] System Design in XP... what are your results?

                              James said:
                              .
                              However, one member of the audience brought up that they have observed
                              that many times the design that is done in XP is influenced by the
                              pressure of "making the date" (I know this is really a management
                              thing, but it is a pressure that developers sometimes feel netherless)
                              and as a result sometimes the design is simple, yet only focuses on
                              solving the task at hand, and as a result when the system grows
                              larger, sometimes the design is a patched together small designs and
                              doesn't really fit coherently.


                              James,

                              I've been thinking about your post for some time, and without context of the original speaker, I can only comment from experience. What I have experienced is that as soon as the feedback drops within the team, and pairing is not done as much as it ought to be, cracks emerge. I feel that the team needs to be conscious of the values and principles of XP, because when they are not, rot sets in.

                              On one project I experienced little pairing during to the environment, and members of the team trying to assert themselves within the organization made fundamental decisions without the rest of the team. Similarly there would be mini-design discussions that involved macro-design changes. At this point I recognized the team had a breakdown in knowledge of the overall system metaphor (in this case it had changed completely). Without forcing a team "regroup" to discuss the situation and the fundamental design changes that had taken place, collective code-ownership started to dwindle and expert silos emerged. At the core was a lack of feedback and communication.

                              So I agree with George Dwindie in that what is of greater importance is in understanding where things started to go wrong (assuming they did) for the resulting drop design quality. Nevertheless, utopia is not a place I have built software from, and these things do happen. Often it comes back down to communication and feedback. Even though there are pressures of deadlines, I ask that our team together is made aware of any code-debt that might be needed, and the team makes a decisions. Without this, a pair or single programmer could make that decision without consultation. Once complete, the programmer might raise the fact code-debt was taken on, and in worse cases nothing is said at all. In the end, what I have observed is that the team says, "We need to do a lot of refactoring to give the code some TLC." In many cases it didnt need to be that way...




                              Nick Robinson
                              Lab49, Inc
                              http://www.lab49.com <http://www.lab49.com/>
                              http://blog.lab49.com <http://blog.lab49.com/>


                              [Non-text portions of this message have been removed]
                            • dnicolet99
                              ... is invariably ... then ... Both these descriptions sound like the same process smell to me - symptoms that people aren t doing incremental refactoring as
                              Message 14 of 14 , Nov 10, 2006
                                > James Carr wrote:

                                > ...when the system grows
                                > larger, sometimes the design is a patched together small designs and
                                > doesn't really fit coherently.

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

                                > We notice that, in order to take the next step, the problem we face
                                is invariably
                                > either "To take the next stepp, we have to (do XYZ) in about 12
                                > different places" or "The next change ripples to there, then there,
                                then
                                > there... oy, that's a long way!"

                                Both these descriptions sound like the same "process smell" to me -
                                symptoms that people aren't doing incremental refactoring as they go
                                along, and they get hit with a big bill from the Design Debt
                                Collection Agency.
                              Your message has been successfully submitted and would be delivered to recipients shortly.