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

RE: [XP] Question about XP and Architecture (part 2)

Expand Messages
  • Steven Gordon
    I have two questions about your scenario: 1. How would one discover these architectural challenges ? - From the customer s initial stories? - From some
    Message 1 of 17 , Jul 3, 2003
    • 0 Attachment
      I have two questions about your scenario:

      1. How would one discover these "architectural challenges"?
      - From the customer's initial stories?
      - From some BDUF-like effort?
      - From experience?

      2. What would be the problem with letting these architectural challenges
      evolve as you implement the most critical stories? If they are the central
      challenges, they will appear as objects being utilized by these stories -
      in most cases, initially mock objects to support the testing of the objects
      that provide the direct business value.

      -----Original Message-----
      From: Charlie Alfred [mailto:calfred@...]
      Sent: Thursday, July 03, 2003 12:03 PM
      To: extremeprogramming@yahoogroups.com
      Subject: [XP] Question about XP and Architecture (part 2)


      Hi,

      This is a follow-on to my earlier post. I wanted to try to pose a scenario
      in order to better illustrate the question of how XP and software
      architecture
      interrelate.

      Kent posed the question:

      >
      > So, here's my challenge. Let's say we identify 15 key challenges. Can we
      > address one of them a week for the first 15 weeks, and still deliver
      > business functionality every week?
      >

      My immediate thought is that you might have to partially address the most
      important
      3 or 4 challenges in the first week, but not completely solve all of them.
      While
      it's unlikely that you can completely solve any of these challenges in a
      week, you *can* ensure that your approach from day one is guided by them.

      Here's an example:

      Suppose I need to design a system to manage the baggage loading/unloading
      operation
      at a major airport. I have 50-100 people per shift driving all those
      baggage
      trucks/carts around, moving luggage between connecting flights, and to/from
      the
      terminal.

      I might know very early on that three of the biggest architecture challenges
      are:

      1. scheduling algorithms that:
      a. use baggage handlers (drivers) efficiently,
      b. co-exist peacefully with control decisions made by human
      dispatchers,
      c. run fast (1-2 minutes for 50-100 drivers and 1000's of
      connections), and
      d. can co-exist with changes that occur while a schedule is being
      developed.

      2. ruggedized hardware and software for the driver's handheld computers
      (rain,
      snow, and temperature ranges from -20 to 120).

      3. highly-available communications between the dispatching system and
      handheld computers carried by each baggage handler, and

      It's unlikely that I will solve any of these problems in week 1. It's also
      likely
      that people might be working on parts of the system that neighbor or
      otherwise
      impact these areas.

      I might need to start work on a messaging system in week 1. I might want to
      have
      a rudimentary system that allows other components of the system to
      interoperate.
      While I might not solve the problem of highly-available messaging in week
      one,
      I need to be aware that it is a requirement. Some important questions are:

      o how many clients will the messaging system have? (several dozens)
      o how many of them will be commnicating with remote destinations? (most)
      o how many of them will be communicating with baggage handlers? (a dozen
      or two)
      o how much of the highly-available solution will be visible to clients?
      (some)
      (versus how much of it is completely behind the scenes?)

      As I understand XP, I shouldn't really be designing for requirements that
      aren't
      immediate. In this case, it's not 100% clear to me how to view the
      highly-available
      messaging requirement:

      o it's VERY immediate, from the standpoint that I don't have viable
      system
      without highly-available communications.

      o it's NOT immediate, from the standpoint that it might take several
      months to
      pull it all together. In the meantime, I need to have a
      non-highly-available
      messaging system in order for development to proceed. This
      non-highly-available
      solution is a temporary solution; I don't ever intend to ship it.

      My concern is that a messaging system design that isn't thinking about
      issues
      regarding high-availability communications with RF network devices from the
      start
      is taking a huge risk. In other words, it's extremely difficult to take a
      messaging system and just add on a high-availability quality attribute, like
      it was
      just another feature.

      On the other hand, designing highly-available messaging system from the
      start seems
      like it focuses attention on features that are not immediately useful.

      Thoughts?

      Charlie Alfred
      Technical Director
      Foliage Software Systems, Inc.
      168 Middlesex Turnpike
      Burlington, MA 01803

      e. mailto:calfred@...
      p. 781.993.5500 x448



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

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

      ad-free courtesy of objectmentor.com

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



      [Non-text portions of this message have been removed]
    • yahoogroups@jhrothjr.com
      ... From: Charlie Alfred To: extremeprogramming@yahoogroups.com
      Message 2 of 17 , Jul 3, 2003
      • 0 Attachment
        ----- Original Message -----
        From: "Charlie Alfred" <calfred.at.foliage.com@...>
        To: "extremeprogramming@yahoogroups.com"
        <extremeprogramming.at.yahoogroups.com@...>
        Sent: Thursday, July 03, 2003 3:02 PM
        Subject: [XP] Question about XP and Architecture (part 2)


        > Hi,
        >
        > This is a follow-on to my earlier post. I wanted to try to pose a
        scenario
        > in order to better illustrate the question of how XP and software
        architecture
        > interrelate.
        >
        > Kent posed the question:
        >
        > >
        > > So, here's my challenge. Let's say we identify 15 key challenges. Can we
        > > address one of them a week for the first 15 weeks, and still deliver
        > > business functionality every week?
        > >
        >
        > My immediate thought is that you might have to partially address the most
        important
        > 3 or 4 challenges in the first week, but not completely solve all of them.
        While
        > it's unlikely that you can completely solve any of these challenges in a
        > week, you *can* ensure that your approach from day one is guided by them.
        >
        > Here's an example:
        >
        > Suppose I need to design a system to manage the baggage loading/unloading
        operation
        > at a major airport. I have 50-100 people per shift driving all those
        baggage
        > trucks/carts around, moving luggage between connecting flights, and
        to/from the
        > terminal.
        >
        > I might know very early on that three of the biggest architecture
        challenges are:
        >
        > 1. scheduling algorithms that:
        > a. use baggage handlers (drivers) efficiently,
        > b. co-exist peacefully with control decisions made by human
        dispatchers,
        > c. run fast (1-2 minutes for 50-100 drivers and 1000's of
        connections), and
        > d. can co-exist with changes that occur while a schedule is being
        developed.
        >
        > 2. ruggedized hardware and software for the driver's handheld
        computers (rain,
        > snow, and temperature ranges from -20 to 120).
        >
        > 3. highly-available communications between the dispatching system and
        > handheld computers carried by each baggage handler, and
        >
        > It's unlikely that I will solve any of these problems in week 1. It's
        also likely
        > that people might be working on parts of the system that neighbor or
        otherwise
        > impact these areas.
        >
        > I might need to start work on a messaging system in week 1. I might want
        to have
        > a rudimentary system that allows other components of the system to
        interoperate.
        > While I might not solve the problem of highly-available messaging in week
        one,
        > I need to be aware that it is a requirement. Some important questions
        are:
        >
        > o how many clients will the messaging system have? (several dozens)
        > o how many of them will be commnicating with remote destinations?
        (most)
        > o how many of them will be communicating with baggage handlers? (a
        dozen or two)
        > o how much of the highly-available solution will be visible to
        clients? (some)
        > (versus how much of it is completely behind the scenes?)
        >
        > As I understand XP, I shouldn't really be designing for requirements that
        aren't
        > immediate. In this case, it's not 100% clear to me how to view the
        highly-available
        > messaging requirement:
        >
        > o it's VERY immediate, from the standpoint that I don't have viable
        system
        > without highly-available communications.
        >
        > o it's NOT immediate, from the standpoint that it might take several
        months to
        > pull it all together. In the meantime, I need to have a
        non-highly-available
        > messaging system in order for development to proceed. This
        non-highly-available
        > solution is a temporary solution; I don't ever intend to ship it.
        >
        > My concern is that a messaging system design that isn't thinking about
        issues
        > regarding high-availability communications with RF network devices from
        the start
        > is taking a huge risk. In other words, it's extremely difficult to take a
        > messaging system and just add on a high-availability quality attribute,
        like it was
        > just another feature.
        >
        > On the other hand, designing highly-available messaging system from the
        start seems
        > like it focuses attention on features that are not immediately useful.
        >
        > Thoughts?

        What would the clients see that is different between the two solutions?
        A rather unsophisticated guess is that the clients would not be able to
        bound the communication delay, which in turn affects their design
        assumptions of what's possible. That, in turn, could be put into the
        acceptance test suite, if not the unit tests suite.

        John Roth





        > Charlie Alfred
        > Technical Director
        > Foliage Software Systems, Inc.
        > 168 Middlesex Turnpike
        > Burlington, MA 01803
        >
        > e. mailto:calfred@...
        > p. 781.993.5500 x448
      • calfred56
        Hi Steven, The first post (titled Question about XP and Architecture) down near the bottom has a more complete explaination. However, a quick summary is: 1.
        Message 3 of 17 , Jul 3, 2003
        • 0 Attachment
          Hi Steven,

          The first post (titled Question about XP and Architecture) down
          near the bottom has a more complete explaination. However, a
          quick summary is:

          1. The customer has an initial set of stories about what they
          need the system to do. Mostly these stories focus on
          features and behavior, but they often contain statements
          that describe "quality of service" expectations.

          2. Other of these quality attributes are things that tend to
          exist in virtually very system (throughput, response time,
          latency, security, availability, etc.). If the customer
          doesn't mention them explicitly, it's easy to ask about them.

          3. Not all quality attributes are equally important to the
          customers. Sometimes, different stakeholders will disagree
          on the relative importance of two quality attributes.

          4. Architecture challenges occur when some factor external to
          the system makes it difficult to achieve that quality
          attribute. For example, the small screen resolution for a
          Web browser on a cell phone or PDA creates a challenge for
          an easy to use user interface.

          5. Prior experience, of both the developer and the customer
          is the typical way that you identify where these challenges
          are.

          6. The most significant challenges are the ones where:

          a. A high-priority quality attribute is jeopardized,
          b. The impact of the external factor on the quality-attribute
          is large, and
          c. There are a limited number of possible solutions.

          The question about letting the architecture challenges evolve is
          an interesting one. It's been my experience that one of the main
          differences between quality attributes and features is that many
          features are additive, while many quality attributes are not.
          Part of the problem is that quality attributes often represent
          cross-cutting concerns that touch a high percentage of objects in
          the system.

          For example: how do I go about increasing the up-time of a system
          from 99% to 99.9999%? It's more difficult than simply addinghosts.
          Perhaps none of my components were originally designed to be used
          remotely? Or perhaps my components have hard-coded knowledge of
          the object(s) that provide services for them.

          Finally, I'm afraid I'm unfamiliar with the BDUF acronym.

          Charlie

          --- In extremeprogramming@yahoogroups.com, Steven Gordon
          <sagordon@a...> wrote:
          > I have two questions about your scenario:
          >
          > 1. How would one discover these "architectural challenges"?
          > - From the customer's initial stories?
          > - From some BDUF-like effort?
          > - From experience?
          >
          > 2. What would be the problem with letting these architectural
          challenges
          > evolve as you implement the most critical stories? If they are the
          central
          > challenges, they will appear as objects being utilized by these
          stories -
          > in most cases, initially mock objects to support the testing of the
          objects
          > that provide the direct business value.
          >
          > -----Original Message-----
          > From: Charlie Alfred [mailto:calfred@f...]
          > Sent: Thursday, July 03, 2003 12:03 PM
          > To: extremeprogramming@yahoogroups.com
          > Subject: [XP] Question about XP and Architecture (part 2)
          >
          >
          > Hi,
          >
          > This is a follow-on to my earlier post. I wanted to try to pose a
          scenario
          > in order to better illustrate the question of how XP and software
          > architecture
          > interrelate.
          >
          > Kent posed the question:
          >
          > >
          > > So, here's my challenge. Let's say we identify 15 key challenges.
          Can we
          > > address one of them a week for the first 15 weeks, and still
          deliver
          > > business functionality every week?
          > >
          >
          > My immediate thought is that you might have to partially address
          the most
          > important
          > 3 or 4 challenges in the first week, but not completely solve all
          of them.
          > While
          > it's unlikely that you can completely solve any of these challenges
          in a
          > week, you *can* ensure that your approach from day one is guided by
          them.
          >
          > Here's an example:
          >
          > Suppose I need to design a system to manage the baggage
          loading/unloading
          > operation
          > at a major airport. I have 50-100 people per shift driving all
          those
          > baggage
          > trucks/carts around, moving luggage between connecting flights, and
          to/from
          > the
          > terminal.
          >
          > I might know very early on that three of the biggest architecture
          challenges
          > are:
          >
          > 1. scheduling algorithms that:
          > a. use baggage handlers (drivers) efficiently,
          > b. co-exist peacefully with control decisions made by human
          > dispatchers,
          > c. run fast (1-2 minutes for 50-100 drivers and 1000's of
          > connections), and
          > d. can co-exist with changes that occur while a schedule
          is being
          > developed.
          >
          > 2. ruggedized hardware and software for the driver's handheld
          computers
          > (rain,
          > snow, and temperature ranges from -20 to 120).
          >
          > 3. highly-available communications between the dispatching
          system and
          > handheld computers carried by each baggage handler, and
          >
          > It's unlikely that I will solve any of these problems in week 1.
          It's also
          > likely
          > that people might be working on parts of the system that neighbor or
          > otherwise
          > impact these areas.
          >
          > I might need to start work on a messaging system in week 1. I
          might want to
          > have
          > a rudimentary system that allows other components of the system to
          > interoperate.
          > While I might not solve the problem of highly-available messaging
          in week
          > one,
          > I need to be aware that it is a requirement. Some important
          questions are:
          >
          > o how many clients will the messaging system have? (several
          dozens)
          > o how many of them will be commnicating with remote
          destinations? (most)
          > o how many of them will be communicating with baggage handlers?
          (a dozen
          > or two)
          > o how much of the highly-available solution will be visible to
          clients?
          > (some)
          > (versus how much of it is completely behind the scenes?)
          >
          > As I understand XP, I shouldn't really be designing for
          requirements that
          > aren't
          > immediate. In this case, it's not 100% clear to me how to view the
          > highly-available
          > messaging requirement:
          >
          > o it's VERY immediate, from the standpoint that I don't have
          viable
          > system
          > without highly-available communications.
          >
          > o it's NOT immediate, from the standpoint that it might take
          several
          > months to
          > pull it all together. In the meantime, I need to have a
          > non-highly-available
          > messaging system in order for development to proceed. This
          > non-highly-available
          > solution is a temporary solution; I don't ever intend to ship
          it.
          >
          > My concern is that a messaging system design that isn't thinking
          about
          > issues
          > regarding high-availability communications with RF network devices
          from the
          > start
          > is taking a huge risk. In other words, it's extremely difficult to
          take a
          > messaging system and just add on a high-availability quality
          attribute, like
          > it was
          > just another feature.
          >
          > On the other hand, designing highly-available messaging system from
          the
          > start seems
          > like it focuses attention on features that are not immediately
          useful.
          >
          > Thoughts?
          >
          > Charlie Alfred
          > Technical Director
          > Foliage Software Systems, Inc.
          > 168 Middlesex Turnpike
          > Burlington, MA 01803
          >
          > e. mailto:calfred@f...
          > p. 781.993.5500 x448
          >
          >
          >
          > To Post a message, send it to: extremeprogramming@e...
          >
          > To Unsubscribe, send a blank message to:
          > extremeprogramming-unsubscribe@e...
          >
          > ad-free courtesy of objectmentor.com
          >
          > Your use of Yahoo! Groups is subject to
          http://docs.yahoo.com/info/terms/
          >
          >
          >
          > [Non-text portions of this message have been removed]
        • John Brewer
          ... Big Design Up Front. That s when you spend months or years on the design phase before codiing. John Brewer Jera Design Extreme Programming FAQ:
          Message 4 of 17 , Jul 3, 2003
          • 0 Attachment
            --- In extremeprogramming@yahoogroups.com, "calfred56" <calfred@f...> wrote:
            > Finally, I'm afraid I'm unfamiliar with the BDUF acronym.

            Big Design Up Front. That's when you spend months or years on the design phase
            before codiing.

            John Brewer
            Jera Design

            Extreme Programming FAQ: http://www.jera.com/techinfo/xpfaq.html
          • Dale Emery
            Hi Charlie, ... Do you consider the limitations of available technology to be internal or external to the system? If you see it as external, I agree with
            Message 5 of 17 , Jul 3, 2003
            • 0 Attachment
              Hi Charlie,

              > 4. Architecture challenges occur when some factor external to
              > the system makes it difficult to achieve that quality
              > attribute.

              Do you consider "the limitations of available technology" to be
              internal or external to the system? If you see it as external, I
              agree with you.

              Dale

              --
              Dale Emery -- Consultant -- Resistance as a Resource
              Web: http://www.dhemery.com
              Weblog: http://www.dhemery.com/journal (Conversations with Dale)
            • calfred56
              ... solutions? ... able to ... In this example, probably not a lot. It s likely that the message system client would want to know that a message was
              Message 6 of 17 , Jul 3, 2003
              • 0 Attachment
                --- In extremeprogramming@yahoogroups.com, yahoogroups@j... wrote:
                >
                > What would the clients see that is different between the two
                solutions?
                > A rather unsophisticated guess is that the clients would not be
                able to
                > bound the communication delay, which in turn affects their design
                > assumptions of what's possible. That, in turn, could be put into the
                > acceptance test suite, if not the unit tests suite.
                >
                > John Roth
                >

                In this example, probably not a lot. It's likely that the
                message system client would want to know that a message was
                undeliverable and maybe what the reason is. This means that the
                client might need to implement a callback API (since it's likely
                that the message system wouldn't know about the inability to
                deliver the message when the client handed it off).

                On the other hand, some messaging system clients might have a
                message that is so important to their goal that they want to block
                for a certain period of time to get positive confirmation of
                delivery.

                An example where there is more impact on the client might be
                access control. Many systems use role-based authorization.
                This uses the following canonical questions:

                1. Which roles are authorized to perform Operation O?
                2. Is Actor A authorized to play role R?

                In some cases, simple role-based authorization is inadequate.
                For example, the canonical question might be:

                1. Can Actor A playing role R on behalf of Legal Entity L
                perform Operation O on Element E.

                In this case, imagine that the element is a confidential legal
                document, and actor A is a lawyer who has power of attorney for
                legal entity L, and the operation is to sign it.

                A can do this in the role of "power of attorney" as long as
                Element E is a legal document that pertains to legal entity L.
                Change A, R, L, O, or E in this canonical question and the
                answer might be different.

                There are two interesting issues with this example:

                a. Virtually all of the parameters needed to address the
                access control question must come from the client who's
                about to perform the operation.

                b. Clients of access control are widely distributed throughout
                the system.

                It's certainly possible to start out with the simplified
                role-based authorization question, and implement clients and a
                service provider who use this model as the basis for their service
                contract.

                Later, when we discover the wider need we can,

                a. Change the contract and change every client that uses it,
                b. Extend the contract and identify which clients need to be
                modified to use the extended contract.

                Another alternative is to define the API for the wider access control
                contract and implement support for the features incrementally.

                Charlie
              • calfred56
                Thanks! My hope with the architecture challenges approach is that it doesn t need to be BDUF. It s been my experience that you don t have to solve *all* of the
                Message 7 of 17 , Jul 3, 2003
                • 0 Attachment
                  Thanks!

                  My hope with the architecture challenges approach is that it
                  doesn't need to be BDUF.

                  It's been my experience that you don't have to solve *all* of the
                  problems up front, as long as you can identify most (or all) of
                  the really critical ones.

                  If I were to go hiking overnight in Wyoming, I might not want to
                  plan my entire route up front. However, I'd want to make
                  sure I had enough water, and that I had a contingency plan to
                  deal with grizzly and black bears.

                  Charlie

                  --- In extremeprogramming@yahoogroups.com, "John Brewer"
                  <jbrewer@j...> wrote:
                  > --- In extremeprogramming@yahoogroups.com, "calfred56"
                  <calfred@f...> wrote:
                  > > Finally, I'm afraid I'm unfamiliar with the BDUF acronym.
                  >
                  > Big Design Up Front. That's when you spend months or years on the
                  design phase
                  > before codiing.
                  >
                  > John Brewer
                  > Jera Design
                  >
                  > Extreme Programming FAQ: http://www.jera.com/techinfo/xpfaq.html
                • calfred56
                  Hi Dale, Yes. Limitations of the available technology definitely qualfies as an external factor. I tend to group external factors into: a. Uncontrollable
                  Message 8 of 17 , Jul 3, 2003
                  • 0 Attachment
                    Hi Dale,

                    Yes. "Limitations of the available technology" definitely
                    qualfies as an external factor.

                    I tend to group external factors into:

                    a. Uncontrollable forces laws of physics, chemistry and
                    mathematics (e.g. Non-polynomial
                    complete problems)

                    b. Imposed constraints laws, government regulations,
                    contractual agreements, industry
                    standards, and customer-imposed
                    technology choices.

                    The difference between the two categories is that the former are
                    absolute, while the latter you might have some recourse over.

                    "Limitations of the available technology" falls somewhere between
                    these two categories. I'd lean toward Imposed Constraints, because
                    it is something that somebody might be able to change. On the
                    other hand, the distinction between uncontrollable forces and
                    and imposed constraints is largely shades of grey anyway.

                    With imposed constraints, you have some choice between addressing
                    the challenge or removing the constraint (e.g. a customer technology
                    requirement creates a huge obstacle). With uncontrollable forces,
                    you have no choice but to address it.

                    Charlie

                    --- In extremeprogramming@yahoogroups.com, Dale Emery <dale@d...>
                    wrote:
                    > Hi Charlie,
                    >
                    > > 4. Architecture challenges occur when some factor external to
                    > > the system makes it difficult to achieve that quality
                    > > attribute.
                    >
                    > Do you consider "the limitations of available technology" to be
                    > internal or external to the system? If you see it as external, I
                    > agree with you.
                    >
                    > Dale
                    >
                    > --
                    > Dale Emery -- Consultant -- Resistance as a Resource
                    > Web: http://www.dhemery.com
                    > Weblog: http://www.dhemery.com/journal (Conversations with Dale)
                  • yahoogroups@jhrothjr.com
                    ... From: calfred56 To: extremeprogramming@yahoogroups.com
                    Message 9 of 17 , Jul 4, 2003
                    • 0 Attachment
                      ----- Original Message -----
                      From: "calfred56" <calfred.at.foliage.com@...>
                      To: "extremeprogramming@yahoogroups.com"
                      <extremeprogramming.at.yahoogroups.com@...>
                      Sent: Thursday, July 03, 2003 4:09 PM
                      Subject: Re: [XP] Question about XP and Architecture (part 2)


                      > --- In extremeprogramming@yahoogroups.com, yahoogroups@j... wrote:
                      > >
                      > > What would the clients see that is different between the two
                      > solutions?
                      > > A rather unsophisticated guess is that the clients would not be
                      > able to
                      > > bound the communication delay, which in turn affects their design
                      > > assumptions of what's possible. That, in turn, could be put into the
                      > > acceptance test suite, if not the unit tests suite.
                      > >
                      > > John Roth
                      > >
                      >
                      > In this example, probably not a lot. It's likely that the
                      > message system client would want to know that a message was
                      > undeliverable and maybe what the reason is. This means that the
                      > client might need to implement a callback API (since it's likely
                      > that the message system wouldn't know about the inability to
                      > deliver the message when the client handed it off).

                      I would think that an undeliverable message would be something
                      that could happen in both scenarios.

                      The point I was trying to get across was that it would be a
                      real good idea to define the difference in the context of the
                      application, so that the new, high-reliability message system
                      could be dropped in without having to rework the clients.

                      In a sense, the original, not-so-reliable message system can
                      be regarded as a simulator for the later system, and could
                      even be instrumented in ways that the eventual production
                      system wouldn't be.

                      This is one of those places where you have to assess
                      risk: how much rework is going to need to be done if
                      you change the interface definition? If it turns out to be
                      relatively low, you plunge ahead. If it turns out to be
                      relatively high, you buy some insurance by doing
                      a more thorough job of analysis and interface design.

                      John Roth
                    • calfred56
                      John, I couldn t agree more. It sounds like what you re saying is that: You Aren t Gonna Need It != You Aren t Gonna Need It Now In some cases, the fact that
                      Message 10 of 17 , Jul 4, 2003
                      • 0 Attachment
                        John,

                        I couldn't agree more.

                        It sounds like what you're saying is that:

                        You Aren't Gonna Need It != You Aren't Gonna Need It Now

                        In some cases, the fact that you don't need a feature this week
                        (or this cycle) must get tempered by:

                        a. there's a pretty good chance that you will need it, eventually
                        b. at the time you will need it, there's a pretty good chance
                        that it will have an API impact, and
                        c. the API is clear, even though the implementation details
                        might not be.

                        In this case, putting the extended API in place is a risk reducer
                        that allows the API to remain stable through the point where the
                        feature is implemented.

                        I think that (a) and (b) are fairly straightforward judgements to
                        make. (c) can more difficult.

                        Charlie

                        > This is one of those places where you have to assess
                        > risk: how much rework is going to need to be done if
                        > you change the interface definition? If it turns out to be
                        > relatively low, you plunge ahead. If it turns out to be
                        > relatively high, you buy some insurance by doing
                        > a more thorough job of analysis and interface design.
                        >
                        > John Roth
                      • Kevin Smith
                        ... Real-world metaphors can be helpful, but they can also be misleading. In this case, imagine that you are going camping in the training grounds of The
                        Message 11 of 17 , Jul 4, 2003
                        • 0 Attachment
                          On Thu, 2003-07-03 at 13:13, calfred56 wrote:
                          > If I were to go hiking overnight in Wyoming, I might not want to
                          > plan my entire route up front. However, I'd want to make
                          > sure I had enough water, and that I had a contingency plan to
                          > deal with grizzly and black bears.

                          Real-world metaphors can be helpful, but they can also be misleading.

                          In this case, imagine that you are going camping in the training grounds
                          of The Matrix. At any time, you can call home base and ask them to send
                          you a sleeping bag or a gun, and it will appear within seconds. Would
                          you still worry so much about packing and contingency plans?

                          That's more how I see software development. Particularly in smaller
                          projects than those that you are really interested in. I would say my
                          focus and interest is in projects up to about 10-person-years, rather
                          than those that are over that threshold.

                          Kevin
                        • Kevin Smith
                          ... If you control all the clients and all the servers, then I don t see much risk in changing API s. It would be risky if you are publishing the API for
                          Message 12 of 17 , Jul 4, 2003
                          • 0 Attachment
                            On Fri, 2003-07-04 at 05:11, calfred56 wrote:
                            > In this case, putting the extended API in place is a risk reducer
                            > that allows the API to remain stable through the point where the
                            > feature is implemented.

                            If you control all the clients and all the servers, then I don't see
                            much risk in changing API's. It would be risky if you are publishing the
                            API for others to implement, or if your clients are in remote areas
                            where it is difficult to upgrade, or if you choose ROM instead of flash
                            to store the code.

                            As long as the team has full control over the API, I think putting in an
                            "extended API" before it is really needed _adds_ risk, because it makes
                            everything more complex and confusing.

                            Kevin
                          • calfred56
                            ... misleading. ... Since they can be misleading, it s a perfect time to introduce a new one :-) ... grounds ... send ... Would ... The key thing about risk is
                            Message 13 of 17 , Jul 4, 2003
                            • 0 Attachment
                              wrote:
                              > On Thu, 2003-07-03 at 13:13, calfred56 wrote:
                              > > If I were to go hiking overnight in Wyoming, I might not want to
                              > > plan my entire route up front. However, I'd want to make
                              > > sure I had enough water, and that I had a contingency plan to
                              > > deal with grizzly and black bears.
                              >
                              > Real-world metaphors can be helpful, but they can also be
                              misleading.
                              >

                              Since they can be misleading, it's a perfect time to introduce
                              a new one :-)

                              > In this case, imagine that you are going camping in the training
                              grounds
                              > of The Matrix. At any time, you can call home base and ask them to
                              send
                              > you a sleeping bag or a gun, and it will appear within seconds.
                              Would
                              > you still worry so much about packing and contingency plans?
                              >

                              The key thing about risk is that it is the combination of two
                              elements:

                              a. the likelihood that something catastrophic will happen, and
                              b. the severity of the impact if it does.

                              If the likelihood is zero, then there's no risk. If the likelihood
                              is small, but the impact is catastrophic, then there's serious
                              risk. The Challenger and Columbia shuttle missions have taught
                              us that lesson. In the Columbia case, both the probability and
                              impact were underestimated (and the mission continued) at the
                              point where it might have been possible to save the crew.

                              > That's more how I see software development. Particularly in smaller
                              > projects than those that you are really interested in.

                              I'm not sure I'd say I have a preference for them, as much as that's
                              where my job has taken me.

                              > I would say my
                              > focus and interest is in projects up to about 10-person-years,
                              > rather than those that are over that threshold.
                              >
                              > Kevin
                            • William Pietri
                              ... So far, my best answer to this question is: gradually. One important thing to note is that things like uptime and scalability aren t stories. A story is
                              Message 14 of 17 , Jul 4, 2003
                              • 0 Attachment
                                On Thu, 2003-07-03 at 12:49, calfred56 wrote:
                                >
                                > For example: how do I go about increasing the up-time of a system
                                > from 99% to 99.9999%? It's more difficult than simply addinghosts.
                                > Perhaps none of my components were originally designed to be used
                                > remotely? Or perhaps my components have hard-coded knowledge of
                                > the object(s) that provide services for them.

                                So far, my best answer to this question is: gradually.

                                One important thing to note is that things like uptime and scalability
                                aren't stories. A story is something like "100 people use the app
                                simultaneously," or "We are hit with a two hour blackout with no service
                                interruptions."

                                When customers have requirements like this, I write out a few graduated
                                story cards. E.g., "{1, 2, 10, 100, 1000} people user the app
                                simultaneously." Then I let the customer shuffle them into the deck
                                where they please.

                                So for the airport baggage system, I would make the customer start with
                                the card that gets a minimal system working, like "Driver receives a
                                10-character message from the dispatcher 20 feet away." Then we would
                                come up with cards both about features:

                                * driver replies
                                * driver reminded of unacknowledged message
                                * driver automatically notified of delayed plane

                                and about reliability

                                * undelivered message retried until delivery
                                * dispatcher warned about messages undelivered for more than 5
                                minutes
                                * messages delivered to 100-foot range
                                * messages delivered to 1000-foot range
                                * messages delivered through walls
                                * messages delivered anywhere on O'Hare grounds

                                and then I'd let the customer shuffle them in business value order.
                                However, if I knew that some story was technically risky, I would let
                                them know. Technical risk implies business risk, and it might be that
                                doing the O'Hare card early would, by reducing business risk, provide
                                lots of business value.

                                William

                                --
                                brains for sale: http://scissor.com/
                              • Anne & Larry Brunelle
                                ... I suppose it s already been noted in this thread (I can t keep up with th traffic) that this is not, per se, a programming problem, but I ll just babble
                                Message 15 of 17 , Jul 4, 2003
                                • 0 Attachment
                                  William Pietri wrote:
                                  > On Thu, 2003-07-03 at 12:49, calfred56 wrote:
                                  >
                                  >>For example: how do I go about increasing the up-time of a system
                                  >>from 99% to 99.9999%? It's more difficult than simply addinghosts.
                                  >>Perhaps none of my components were originally designed to be used
                                  >>remotely? Or perhaps my components have hard-coded knowledge of
                                  >>the object(s) that provide services for them.
                                  >
                                  >
                                  > So far, my best answer to this question is: gradually.
                                  >
                                  > One important thing to note is that things like uptime and scalability
                                  > aren't stories. A story is something like "100 people use the app
                                  > simultaneously," or "We are hit with a two hour blackout with no service
                                  > interruptions."
                                  >
                                  > When customers have requirements like this, I write out a few graduated
                                  > story cards. E.g., "{1, 2, 10, 100, 1000} people user the app
                                  > simultaneously." Then I let the customer shuffle them into the deck
                                  > where they please.

                                  I suppose it's already been noted in this thread (I
                                  can't keep up with th traffic) that this is not, per
                                  se, a programming problem, but I'll just babble that
                                  proposition anyway.

                                  Although the solution may require new programming or
                                  refactoring, this issue is a system requirement. And
                                  addressing it indeed requires some system stories.

                                  For instance, what is uptime in context? On a telecom
                                  switch, it means up, starting calls, ending calls, and,
                                  quite particularly, not dropping calls. That last
                                  inherently requires more immediate redundancy than, say,
                                  a webserver. (The programming impact for that redundancy
                                  might be zero.) For the webserver, uptime might well mean
                                  something less demanding: are we "up" if 10,000 hits
                                  are serviced in 5 minutes, even if a couple of clients
                                  had to resubmit their requests? (For, of course, THAT
                                  might happen for reasons outside of our network.)

                                  And how do you test for "five-9s" in context?

                                  Going back to the question of components not
                                  designed for remote use: having had to code for
                                  stuff that might migrate among processors, I'd say
                                  that components with, uh, high cohesion and low coupling
                                  (where HAVE we heard THAT before?) can be moved with
                                  minimal grief. And low coupling means (among other
                                  things) that objects (instances) don't know much more
                                  about each other than necessary to request what they
                                  need.
                                • yahoogroups@jhrothjr.com
                                  ... From: William Pietri ... Absolutely right. The story sequence is: committment, conversation,
                                  Message 16 of 17 , Jul 5, 2003
                                  • 0 Attachment
                                    ----- Original Message -----
                                    From: "William Pietri" <william.at.scissor.com@...>
                                    >
                                    > One important thing to note is that things like uptime and scalability
                                    > aren't stories. A story is something like "100 people use the app
                                    > simultaneously," or "We are hit with a two hour blackout with no service
                                    > interruptions."
                                    >
                                    > When customers have requirements like this, I write out a few graduated
                                    > story cards. E.g., "{1, 2, 10, 100, 1000} people user the app
                                    > simultaneously." Then I let the customer shuffle them into the deck
                                    > where they please.

                                    Absolutely right. The story sequence is: committment, conversation,
                                    confirmation.
                                    Confirmation requires being able to write an acceptance test, and you can't
                                    do that for "uptime" without defining exactly how much and under
                                    what conditions.

                                    John Roth

                                    >
                                    >
                                    > William
                                    >
                                  • calfred56
                                    ... addinghosts. ... scalability ... service ... I agree with this. What you re calling system stories, other people (notably the SEI Software Architecture
                                    Message 17 of 17 , Jul 5, 2003
                                    • 0 Attachment
                                      --- In extremeprogramming@yahoogroups.com, Anne & Larry Brunelle
                                      <brunelle@a...> wrote:
                                      > William Pietri wrote:
                                      > > On Thu, 2003-07-03 at 12:49, calfred56 wrote:
                                      > >
                                      > >>For example: how do I go about increasing the up-time of a system
                                      > >>from 99% to 99.9999%? It's more difficult than simply
                                      addinghosts.
                                      > >>Perhaps none of my components were originally designed to be used
                                      > >>remotely? Or perhaps my components have hard-coded knowledge of
                                      > >>the object(s) that provide services for them.
                                      > >
                                      > >
                                      > > So far, my best answer to this question is: gradually.
                                      > >
                                      > > One important thing to note is that things like uptime and
                                      scalability
                                      > > aren't stories. A story is something like "100 people use the app
                                      > > simultaneously," or "We are hit with a two hour blackout with no
                                      service
                                      > > interruptions."
                                      > >

                                      I agree with this. What you're calling system stories, other
                                      people (notably the SEI Software Architecture folks) call
                                      Quality Attribute Scenarios. Both require enough environment
                                      (or context) around the quality to make it testable.

                                      > And how do you test for "five-9s" in context?
                                      >

                                      I apologize if my comment about going from 99% to 99.999% implied
                                      that this was supposed to be an absolute metric. A lot depends
                                      on what is meant by availability, and what conditions threaten it
                                      (weather catastrophe, civil insurrection, denial of service attack,
                                      etc.).

                                      > Going back to the question of components not
                                      > designed for remote use: having had to code for
                                      > stuff that might migrate among processors, I'd say
                                      > that components with, uh, high cohesion and low coupling
                                      > (where HAVE we heard THAT before?) can be moved with
                                      > minimal grief. And low coupling means (among other
                                      > things) that objects (instances) don't know much more
                                      > about each other than necessary to request what they
                                      > need.

                                      My main point was that if this is the type of thing that you are
                                      thinking about (or asking the customer about) early, the better
                                      chance you have of achieving it. It might well be that code with
                                      high-cohesion and low-coupling will automatically scale well.
                                      On the other hand, perhaps it won't.

                                      If while the stories are being developed, the developer is attentive
                                      to undertones of risk conditions (e.g. what might go wrong here)
                                      and asks about them, then the customer is put in a position of
                                      considering them.

                                      Charlie
                                    Your message has been successfully submitted and would be delivered to recipients shortly.