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

RE: [scrumdevelopment] Re: flattened cost of change curve

Expand Messages
  • Ilja Preuss
    ... Ditto... ... I am not at all sure that Barry made this distinction. Actually I d think that having to make a change invariably had to be a reaction to a
    Message 1 of 30 , Oct 1, 2003
    • 0 Attachment
      Edmund Schweppe wrote:
      > I haven't got Kent's White Book in front of me, and I don't have
      > Barry's paper anywhere, so I'm speaking from oft-fragile memory here,
      > but ...

      Ditto...

      > AFAIK, Barry Boehm's research showed the cost of *fixing defects* grew
      > exponentially.
      >
      > AFAIK, Kent Beck's assertion is that the cost of *making changes*
      > under XP does not grow exponentially.
      >
      > AFAIK, *fixing defects* != *making changes*. More specifically, there
      > exist changes to software that do not involve fixing existing defects.
      > (Obviously, fixing a defect involves making a change. Somewhere.)

      I am not at all sure that Barry made this distinction. Actually I'd
      think that having to "make a change" invariably had to be a reaction to
      a "defect in the requirements" for him. At least that's the only way I
      can imagine introducing a "bug" in the "analysis phase" at all...

      Take care, Ilja
    • Edmund Schweppe
      ... I don t think he did either - and that s where I suspect a big part of the problem lies. I keep on seeing references to cost-of-*change* curves which talk
      Message 2 of 30 , Oct 2, 2003
      • 0 Attachment
        Ilja Preuss wrote:
        > Edmund Schweppe wrote:
        >
        >>I haven't got Kent's White Book in front of me, and I don't have
        >>Barry's paper anywhere, so I'm speaking from oft-fragile memory here,
        >>but ...
        >
        >
        > Ditto...
        >
        >
        >>AFAIK, Barry Boehm's research showed the cost of *fixing defects* grew
        >>exponentially.
        >>
        >>AFAIK, Kent Beck's assertion is that the cost of *making changes*
        >>under XP does not grow exponentially.
        >>
        >>AFAIK, *fixing defects* != *making changes*. More specifically, there
        >>exist changes to software that do not involve fixing existing defects.
        >>(Obviously, fixing a defect involves making a change. Somewhere.)
        > I am not at all sure that Barry made this distinction.

        I don't think he did either - and that's where I suspect a big part of
        the problem lies. I keep on seeing references to cost-of-*change* curves
        which talk about how expensive fixing *mistakes* are.

        > Actually I'd
        > think that having to "make a change" invariably had to be a reaction to
        > a "defect in the requirements" for him. At least that's the only way I
        > can imagine introducing a "bug" in the "analysis phase" at all...

        I can imagine two scenarios:
        1) When I'm initially gathering requirements from you, you tell me that
        the app needs to display information in both English and German. I
        misunderstand you (or lose my notes) and deliver an English-only app.
        That would be a "requirements bug".
        2) When I'm initially gathering requirements from you, you tell me that
        the app needs to display information in English. I deliver an
        English-only app; then you tell me that you also need the app to display
        information in German. (For instance, you might have been building a
        payroll system for an American automotive manufacturer who subsequently
        was purchased by a German one :-) That, to me, is a change that's not
        due to a bug in the requirements; instead, it's due to a change in the
        environment.


        >
        > Take care, Ilja
        >
        >
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
        >


        --
        Edmund Schweppe -- schweppe@... -- http://schweppe.home.tiac.net
        The opinions expressed herein are at best coincidentally related to
        those of any past, present or future employer.
      • Ilja Preuss
        ... Yep. ... Yes - though I think in a waterfallish environment it could be seen as a bug, too. You simply didn t do enough analysis upfront - else you should
        Message 3 of 30 , Oct 6, 2003
        • 0 Attachment
          Edmund Schweppe wrote:
          > Ilja Preuss wrote:
          > > Actually I'd
          >> think that having to "make a change" invariably had to be a reaction
          >> to a "defect in the requirements" for him. At least that's the only
          >> way I can imagine introducing a "bug" in the "analysis phase" at
          >> all...
          >
          > I can imagine two scenarios:
          > 1) When I'm initially gathering requirements from you, you tell me
          > that the app needs to display information in both English and German.
          > I misunderstand you (or lose my notes) and deliver an English-only
          > app. That would be a "requirements bug".

          Yep.

          > 2) When I'm initially gathering requirements from you, you tell me
          > that the app needs to display information in English. I deliver an
          > English-only app; then you tell me that you also need the app to
          > display information in German. (For instance, you might have been
          > building a payroll system for an American automotive manufacturer who
          > subsequently was purchased by a German one :-) That, to me, is a
          > change that's not due to a bug in the requirements; instead, it's due
          > to a change in the environment.

          Yes - though I think in a waterfallish environment it could be seen as a
          bug, too. You simply didn't do enough analysis upfront - else you should
          have known that you could need a different language version in the
          future. Because you didn't, you have to restart the whole development
          cycle.

          To an agile team, of course, *both* scenarios just result in another
          feature to be added incrementally. That's why I think that "requirement
          bugs" aren't that important in agile development.

          Regards, Ilja
        Your message has been successfully submitted and would be delivered to recipients shortly.