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

Back of the Door Sticky Note Issue Tracking.

Expand Messages
  • John Carter
    So Alastair Cockburn came by this furthest corner of the planet and gave refreshing breeze of good sense.... But one thing he
    Message 1 of 24 , Mar 12, 2013
    View Source
    • 0 Attachment
      So Alastair Cockburn <http://alistair.cockburn.us/> came by this furthest
      corner of the planet and gave refreshing breeze of good sense....

      But one thing he mentioned, but nobody picked up on, and I had already
      overused my quota of questions....

      He said that some places are working with "sticky notes on the back of the
      door" issue tracking systems.

      ie. They have so few issues that they can track them in this very low tech
      manner.

      I can of course imagine several routes to such a state....

      a) The Obvious and most Desirable route is Magic Happens, and developers
      create so few defects there aren't any defects for the testers to find.

      b) The "lean manufacturing", less desirable, but still sane answer that you
      balance the number of testers, new feature developers, and defect fixers
      until the rates of defect injection, discovery and fix are identical. (No
      queues)

      c) The even less desirable, but still vaguely sanish answer that when the
      sticky notes have covered the door... you start throwing away the least
      important (and rely on the tester's memory that we found that bug before,
      but threw it away).

      d) The totally unacceptable route that you have so few / so weak testers
      that despite an ever growing pool of defects, they aren't finding them.

      Anybody have any experience of what Alastair was talking about?



      --
      John Carter Phone : (64)(3) 358 6639
      Tait Electronics Fax : (64)(3) 359 4632
      PO Box 1645 Christchurch Email : john.carter@...
      New Zealand

      --

      ------------------------------
      This email, including any attachments, is only for the intended recipient.
      It is subject to copyright, is confidential and may be the subject of legal
      or other privilege, none of which is waived or lost by reason of this
      transmission.
      If you are not an intended recipient, you may not use, disseminate,
      distribute or reproduce such email, any attachments, or any part thereof.
      If you have received a message in error, please notify the sender
      immediately and erase all copies of the message and any attachments.
      Unfortunately, we cannot warrant that the email has not been altered or
      corrupted during transmission nor can we guarantee that any email or any
      attachments are free from computer viruses or other conditions which may
      damage or interfere with recipient data, hardware or software. The
      recipient relies upon its own procedures and assumes all risk of use and of
      opening any attachments.
      ------------------------------


      [Non-text portions of this message have been removed]
    • Charlie Poole
      I ve worked with XP teams where every issue reported became a story or a part of a story. We didn t have a bug tracker. Problems found when a story was
      Message 2 of 24 , Mar 12, 2013
      View Source
      • 0 Attachment
        I've worked with XP teams where every issue reported became a story or a
        part of a story. We didn't have a bug tracker.

        Problems found when a story was initially believed to be finished either
        meant the story wasn't finished or that a new story had to be written.
        Problems found later became a (possibly high priority) story.

        I'm pretty sure that working without a bug-tracker requires having everyone
        in one place, which is how I've seen it done.

        Charlie


        On Tue, Mar 12, 2013 at 8:47 PM, John Carter <john.carter@...> wrote:

        > **
        >
        >
        > So Alastair Cockburn <http://alistair.cockburn.us/> came by this furthest
        > corner of the planet and gave refreshing breeze of good sense....
        >
        > But one thing he mentioned, but nobody picked up on, and I had already
        > overused my quota of questions....
        >
        > He said that some places are working with "sticky notes on the back of the
        > door" issue tracking systems.
        >
        > ie. They have so few issues that they can track them in this very low tech
        > manner.
        >
        > I can of course imagine several routes to such a state....
        >
        > a) The Obvious and most Desirable route is Magic Happens, and developers
        > create so few defects there aren't any defects for the testers to find.
        >
        > b) The "lean manufacturing", less desirable, but still sane answer that you
        > balance the number of testers, new feature developers, and defect fixers
        > until the rates of defect injection, discovery and fix are identical. (No
        > queues)
        >
        > c) The even less desirable, but still vaguely sanish answer that when the
        > sticky notes have covered the door... you start throwing away the least
        > important (and rely on the tester's memory that we found that bug before,
        > but threw it away).
        >
        > d) The totally unacceptable route that you have so few / so weak testers
        > that despite an ever growing pool of defects, they aren't finding them.
        >
        > Anybody have any experience of what Alastair was talking about?
        >
        > --
        > John Carter Phone : (64)(3) 358 6639
        > Tait Electronics Fax : (64)(3) 359 4632
        > PO Box 1645 Christchurch Email : john.carter@...
        > New Zealand
        >
        > --
        >
        > ------------------------------
        > This email, including any attachments, is only for the intended recipient.
        > It is subject to copyright, is confidential and may be the subject of
        > legal
        > or other privilege, none of which is waived or lost by reason of this
        > transmission.
        > If you are not an intended recipient, you may not use, disseminate,
        > distribute or reproduce such email, any attachments, or any part thereof.
        > If you have received a message in error, please notify the sender
        > immediately and erase all copies of the message and any attachments.
        > Unfortunately, we cannot warrant that the email has not been altered or
        > corrupted during transmission nor can we guarantee that any email or any
        > attachments are free from computer viruses or other conditions which may
        > damage or interfere with recipient data, hardware or software. The
        > recipient relies upon its own procedures and assumes all risk of use and
        > of
        > opening any attachments.
        > ------------------------------
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >


        [Non-text portions of this message have been removed]
      • Adrian Howard
        I can t speak for Alastair as to what he meant - but there are at least a few more options: i) There are little to no issues being tracked since they are fixed
        Message 3 of 24 , Mar 12, 2013
        View Source
        • 0 Attachment
          I can't speak for Alastair as to what he meant - but there are at
          least a few more options:

          i) There are little to no issues being tracked since they are fixed on
          discovery. They don't hang around because they are treated as
          stop-the-line problems that need immediate attention.

          ii) There's a sharp line between issues that are "we released
          something that doesn't work as we intended it to work" and everything
          else. Only the former are "bugs" - everything else gets pushed into
          the normal backlog and prioritised accordingly.

          ii) There is no separate bug queue - everything is in a single backlog
          and prioritised accordingly.

          iv) There are little or no issues being tracked since the testers and
          the QA folk work with the rest of the team throughout the development
          process so that bugs get caught and fixed during development, rather
          than afterwards.

          In my experience teams with the low bug counts have some of more of
          the above, along with your (a) where "Magic Happens" == a great
          poly-skilled team that includes testers, product managers and business
          input in combination with a stack of good development practices
          applied well.

          Cheers,

          Adrian

          On 13 March 2013 03:47, John Carter <john.carter@...> wrote:
          > So Alastair Cockburn <http://alistair.cockburn.us/> came by this furthest
          > corner of the planet and gave refreshing breeze of good sense....
          >
          > But one thing he mentioned, but nobody picked up on, and I had already
          > overused my quota of questions....
          >
          > He said that some places are working with "sticky notes on the back of the
          > door" issue tracking systems.
          >
          > ie. They have so few issues that they can track them in this very low tech
          > manner.
          >
          > I can of course imagine several routes to such a state....
          >
          > a) The Obvious and most Desirable route is Magic Happens, and developers
          > create so few defects there aren't any defects for the testers to find.
          >
          > b) The "lean manufacturing", less desirable, but still sane answer that you
          > balance the number of testers, new feature developers, and defect fixers
          > until the rates of defect injection, discovery and fix are identical. (No
          > queues)
          >
          > c) The even less desirable, but still vaguely sanish answer that when the
          > sticky notes have covered the door... you start throwing away the least
          > important (and rely on the tester's memory that we found that bug before,
          > but threw it away).
          >
          > d) The totally unacceptable route that you have so few / so weak testers
          > that despite an ever growing pool of defects, they aren't finding them.
          >
          > Anybody have any experience of what Alastair was talking about?
          --
          http://quietstars.com adrianh@... twitter.com/adrianh
          t. +44 (0)7752 419080 skype adrianjohnhoward pinboard.in/u:adrianh
        • George Dinwiddie
          John, I ve seen a team of ordinary programmers reach the state of frequently shipping zero bugs (even measured after deployment), and quickly taking care of
          Message 4 of 24 , Mar 12, 2013
          View Source
          • 0 Attachment
            John,

            I've seen a team of ordinary programmers reach the state of frequently
            shipping zero bugs (even measured after deployment), and quickly taking
            care of the ones that escaped an iteration. It's not magic.

            - George

            On 3/12/13 11:47 PM, John Carter wrote:
            > So Alastair Cockburn <http://alistair.cockburn.us/> came by this furthest
            > corner of the planet and gave refreshing breeze of good sense....
            >
            > But one thing he mentioned, but nobody picked up on, and I had already
            > overused my quota of questions....
            >
            > He said that some places are working with "sticky notes on the back of the
            > door" issue tracking systems.
            >
            > ie. They have so few issues that they can track them in this very low tech
            > manner.
            >
            > I can of course imagine several routes to such a state....
            >
            > a) The Obvious and most Desirable route is Magic Happens, and developers
            > create so few defects there aren't any defects for the testers to find.
            >
            > b) The "lean manufacturing", less desirable, but still sane answer that you
            > balance the number of testers, new feature developers, and defect fixers
            > until the rates of defect injection, discovery and fix are identical. (No
            > queues)
            >
            > c) The even less desirable, but still vaguely sanish answer that when the
            > sticky notes have covered the door... you start throwing away the least
            > important (and rely on the tester's memory that we found that bug before,
            > but threw it away).
            >
            > d) The totally unacceptable route that you have so few / so weak testers
            > that despite an ever growing pool of defects, they aren't finding them.
            >
            > Anybody have any experience of what Alastair was talking about?
            >
            >
            >

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • John Carter
            On Wed, Mar 13, 2013 at 5:20 PM, George Dinwiddie ... This is the Very Interesting Answer which I would like to bring home to the rest of the company.... My
            Message 5 of 24 , Mar 12, 2013
            View Source
            • 0 Attachment
              On Wed, Mar 13, 2013 at 5:20 PM, George Dinwiddie
              <lists@...>wrote:

              > I've seen a team of ordinary programmers reach the state of frequently
              > shipping zero bugs (even measured after deployment), and quickly taking
              > care of the ones that escaped an iteration. It's not magic.
              >

              This is the Very Interesting Answer which I would like to bring home to the
              rest of the company....

              My colleagues are quite comfortable with the "lean manufacturing" no queues
              answer, but plain flat out don't believe the "No Defect Magic" answer.

              So I'm looking for data / evidence / stories / books / papers to convince
              them that we could do better.


              --
              John Carter Phone : (64)(3) 358 6639
              Tait Electronics Fax : (64)(3) 359 4632
              PO Box 1645 Christchurch Email : john.carter@...
              New Zealand

              --

              ------------------------------
              This email, including any attachments, is only for the intended recipient.
              It is subject to copyright, is confidential and may be the subject of legal
              or other privilege, none of which is waived or lost by reason of this
              transmission.
              If you are not an intended recipient, you may not use, disseminate,
              distribute or reproduce such email, any attachments, or any part thereof.
              If you have received a message in error, please notify the sender
              immediately and erase all copies of the message and any attachments.
              Unfortunately, we cannot warrant that the email has not been altered or
              corrupted during transmission nor can we guarantee that any email or any
              attachments are free from computer viruses or other conditions which may
              damage or interfere with recipient data, hardware or software. The
              recipient relies upon its own procedures and assumes all risk of use and of
              opening any attachments.
              ------------------------------


              [Non-text portions of this message have been removed]
            • George Dinwiddie
              John, ... Do you think that will convince them? It didn t even convince the organization around them. The comment on their first release, when 92% of the
              Message 6 of 24 , Mar 12, 2013
              View Source
              • 0 Attachment
                John,

                On 3/13/13 12:42 AM, John Carter wrote:
                > On Wed, Mar 13, 2013 at 5:20 PM, George Dinwiddie
                > <lists@...>wrote:
                >
                >> I've seen a team of ordinary programmers reach the state of frequently
                >> shipping zero bugs (even measured after deployment), and quickly taking
                >> care of the ones that escaped an iteration. It's not magic.
                >>
                >
                > This is the Very Interesting Answer which I would like to bring home to the
                > rest of the company....
                >
                > My colleagues are quite comfortable with the "lean manufacturing" no queues
                > answer, but plain flat out don't believe the "No Defect Magic" answer.
                >
                > So I'm looking for data / evidence / stories / books / papers to convince
                > them that we could do better.

                Do you think that will convince them?

                It didn't even convince the organization around them. The comment on
                their first release, when 92% of the release test scripts passed on the
                first attempt, was "they cheated; they tested ahead of time." I think it
                was the second or third release when they hit 100%.

                Yes, they tested, not always automated. They also had a sign on the wall
                that said "Zero bugs, the new normal."

                - George

                --
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              • Charlie Poole
                Hi George, Maybe we should just say Yes, we cheated. And we figured out a way to keep cheating, so that tests keep passing. Do you want us to stop? Charlie
                Message 7 of 24 , Mar 12, 2013
                View Source
                • 0 Attachment
                  Hi George,

                  Maybe we should just say "Yes, we cheated. And we figured out a way to keep
                  cheating, so that tests keep passing. Do you want us to stop?"

                  Charlie


                  On Tue, Mar 12, 2013 at 9:52 PM, George Dinwiddie
                  <lists@...>wrote:

                  > **
                  >
                  >
                  > John,
                  >
                  > On 3/13/13 12:42 AM, John Carter wrote:
                  > > On Wed, Mar 13, 2013 at 5:20 PM, George Dinwiddie
                  > > <lists@...>wrote:
                  > >
                  > >> I've seen a team of ordinary programmers reach the state of frequently
                  > >> shipping zero bugs (even measured after deployment), and quickly taking
                  > >> care of the ones that escaped an iteration. It's not magic.
                  > >>
                  > >
                  > > This is the Very Interesting Answer which I would like to bring home to
                  > the
                  > > rest of the company....
                  > >
                  > > My colleagues are quite comfortable with the "lean manufacturing" no
                  > queues
                  > > answer, but plain flat out don't believe the "No Defect Magic" answer.
                  > >
                  > > So I'm looking for data / evidence / stories / books / papers to convince
                  > > them that we could do better.
                  >
                  > Do you think that will convince them?
                  >
                  > It didn't even convince the organization around them. The comment on
                  > their first release, when 92% of the release test scripts passed on the
                  > first attempt, was "they cheated; they tested ahead of time." I think it
                  > was the second or third release when they hit 100%.
                  >
                  > Yes, they tested, not always automated. They also had a sign on the wall
                  > that said "Zero bugs, the new normal."
                  >
                  > - George
                  >
                  > --
                  > ----------------------------------------------------------
                  > * George Dinwiddie * http://blog.gdinwiddie.com
                  > Software Development http://www.idiacomputing.com
                  > Consultant and Coach http://www.agilemaryland.org
                  > ----------------------------------------------------------
                  >
                  >
                  >


                  [Non-text portions of this message have been removed]
                • Ron Jeffries
                  Hello, John, ... I have to say that I m a bit surprised to see you asking this question. Alistair s point is that good teams don t have very many defects.
                  Message 8 of 24 , Mar 13, 2013
                  View Source
                  • 0 Attachment
                    Hello, John,

                    On Mar 12, 2013, at 11:47 PM, John Carter <john.carter@...> wrote:

                    > a) The Obvious and most Desirable route is Magic Happens, and developers
                    > create so few defects there aren't any defects for the testers to find.
                    >
                    > b) The "lean manufacturing", less desirable, but still sane answer that you
                    > balance the number of testers, new feature developers, and defect fixers
                    > until the rates of defect injection, discovery and fix are identical. (No
                    > queues)
                    >
                    > c) The even less desirable, but still vaguely sanish answer that when the
                    > sticky notes have covered the door... you start throwing away the least
                    > important (and rely on the tester's memory that we found that bug before,
                    > but threw it away).
                    >
                    > d) The totally unacceptable route that you have so few / so weak testers
                    > that despite an ever growing pool of defects, they aren't finding them.

                    I have to say that I'm a bit surprised to see you asking this question.

                    Alistair's point is that good teams don't have very many defects. Frankly I don't see why they'd need a whole bloody door.

                    The correct option is (a), but it's not done with magic, it's done by being ****ing competent. Let's face it, if developers are creating defects, they are to that extent incompetent.

                    The notion included in (b) seems to think that only testers can find defects and only "defect fixers" can fix them. XP and all Agile methods are about cross-functional teams. The team tests, the team finds defects, the team fixes them.

                    How do they do that?

                    Add testing skill to the development team. One way to do this is to merge the existing testers right in. Clearly the team needs all the necessary skills to develop each feature, yes? Well, if the features are shipping with defects, then clearly the team needs more testing.
                    Use Acceptance Test-Driven Development. Each feature's description includes defined and preferably automated tests (checks) of examples of that feature's correct operation. Developers, not being stupid, do not pass code on until it passes all these tests. See the "Three C's" notion. These are "Customer Tests".
                    Analyze every defect. When defects arise, figure out how each one occurred. Since you are doing Acceptance Test-Driven Development, it is evident that there is at least one missing test. Write that check, plus all the others that occur to you in light of the missing one. Beef up your overall approach to ATDD, improving how you define new tests. Retrofit old tests as indicated.
                    Use Test-Driven Development. Developers write no line of code until they have a failing test asking for that very line of code. These are "Programmer Tests", sometimes called unit tests. As in step 3 above, when defects show up, they also indicate that TDD tests are missing. Write those, learn from it.

                    "Won't that take forever, all that testing? We'll never get done!"

                    You'll never get done now! Your god-blessed bug database is filling up and your thrice-blessed programmers are piling more dead code on top of the existing dead code. When were you planning to fix all these bugs, in Fixtober, Bugvember, and Defectcember? I'm sorry, those months were cancelled. Better fix them now.

                    It takes less time to prevent a defect than to fix it. So invest the time to write the tests before you code, and don't stop coding until the tests work. Voila, bug production drops by an order of magnitude, even if you completely suck at writing tests. If you get good at it, and with all that practice you will get good at it, and it'll drop by another order of magnitude.

                    In short, XP.

                    This topic, and the answer, has been around a long time. A few articles relating to this subject:

                    http://xprogramming.com/articles/which-end-of-the-horse/
                    http://xprogramming.com/articles/expcardconversationconfirmation/
                    http://xprogramming.com/articles/where-can-we-reduce-quality/
                    http://xprogramming.com/blog/discovering-essential-technical-practices/
                    http://xprogramming.com/articles/manual-testing-does-exist-and-it-is-bad/
                    http://xprogramming.com/articles/kate-oneal-handling-defects/

                    Ron Jeffries
                    www.XProgramming.com
                    Perfectionism is the voice of the oppressor -- Anne Lamott



                    [Non-text portions of this message have been removed]
                  • George Dinwiddie
                    Charlie, ... Yes, it was amazing to me that anyone would want to treat software release like a pop test. - George -- ... * George Dinwiddie *
                    Message 9 of 24 , Mar 13, 2013
                    View Source
                    • 0 Attachment
                      Charlie,

                      On 3/13/13 1:57 AM, Charlie Poole wrote:
                      > Hi George,
                      >
                      > Maybe we should just say "Yes, we cheated. And we figured out a way to keep
                      > cheating, so that tests keep passing. Do you want us to stop?"

                      Yes, it was amazing to me that anyone would want to treat software
                      release like a pop test.

                      - George

                      --
                      ----------------------------------------------------------------------
                      * George Dinwiddie * http://blog.gdinwiddie.com
                      Software Development http://www.idiacomputing.com
                      Consultant and Coach http://www.agilemaryland.org
                      ----------------------------------------------------------------------
                    • steveropa
                      I had the same experience, and it actually got me laid off. Our team was consistently producing zero bugs, or if something did escape, it was so small and
                      Message 10 of 24 , Mar 13, 2013
                      View Source
                      • 0 Attachment
                        I had the same experience, and it actually got me laid off. Our team was consistently producing zero bugs, or if something did escape, it was so small and taken care of so quickly that it didn’t register in some system. Our customers were delighted, but our organization felt that we weren’t devoting enough time to fixing bugs, thus we were doing something wrong.



                        When the layoffs came, I was on the block since I clearly wasn't managing the team effectively anyway. I guess since I wasn’t really “managing” the team but supporting it, they were right.



                        Steve



                        Sent from Windows Mail


                        From: George Dinwiddie
                        Sent: ‎March‎ ‎12‎, ‎2013 ‎10‎:‎52‎ ‎PM
                        To: extremeprogramming@yahoogroups.com
                        Subject: Re: [XP] Back of the Door Sticky Note Issue Tracking.






                        John,

                        On 3/13/13 12:42 AM, John Carter wrote:
                        > On Wed, Mar 13, 2013 at 5:20 PM, George Dinwiddie
                        > <lists@...>wrote:
                        >
                        >> I've seen a team of ordinary programmers reach the state of frequently
                        >> shipping zero bugs (even measured after deployment), and quickly taking
                        >> care of the ones that escaped an iteration. It's not magic.
                        >>
                        >
                        > This is the Very Interesting Answer which I would like to bring home to the
                        > rest of the company....
                        >
                        > My colleagues are quite comfortable with the "lean manufacturing" no queues
                        > answer, but plain flat out don't believe the "No Defect Magic" answer.
                        >
                        > So I'm looking for data / evidence / stories / books / papers to convince
                        > them that we could do better.

                        Do you think that will convince them?

                        It didn't even convince the organization around them. The comment on
                        their first release, when 92% of the release test scripts passed on the
                        first attempt, was "they cheated; they tested ahead of time." I think it
                        was the second or third release when they hit 100%.

                        Yes, they tested, not always automated. They also had a sign on the wall
                        that said "Zero bugs, the new normal."

                        - George

                        --
                        ----------------------------------------------------------
                        * George Dinwiddie * http://blog.gdinwiddie.com
                        Software Development http://www.idiacomputing.com
                        Consultant and Coach http://www.agilemaryland.org
                        ----------------------------------------------------------





                        [Non-text portions of this message have been removed]
                      • Ron Jeffries
                        Hi Steve, ... This sounds like a communication problem to me ... was it? Ron Jeffries www.XProgramming.com If another does not intend offense, it is wrong for
                        Message 11 of 24 , Mar 13, 2013
                        View Source
                        • 0 Attachment
                          Hi Steve,

                          On Mar 13, 2013, at 10:19 AM, <steveropa@...> wrote:

                          > I had the same experience, and it actually got me laid off. Our team was consistently producing zero bugs, or if something did escape, it was so small and taken care of so quickly that it didn�t register in some system. Our customers were delighted, but our organization felt that we weren�t devoting enough time to fixing bugs, thus we were doing something wrong.
                          >
                          > When the layoffs came, I was on the block since I clearly wasn't managing the team effectively anyway. I guess since I wasn�t really �managing� the team but supporting it, they were right.


                          This sounds like a communication problem to me ... was it?

                          Ron Jeffries
                          www.XProgramming.com
                          If another does not intend offense, it is wrong for me to seek it;
                          if another does indeed intend offense, it is foolish for me to permit it.
                          -- Kelly Easterley



                          [Non-text portions of this message have been removed]
                        • Curtis Cooley
                          ... Or his organization was so dysfunctional he really won the layoff lottery. -- ... Curtis Cooley curtis@industriallogic.com [Non-text portions of this
                          Message 12 of 24 , Mar 13, 2013
                          View Source
                          • 0 Attachment
                            On Wed, Mar 13, 2013 at 8:51 AM, Ron Jeffries <ronjeffries@...> wrote:

                            > Hi Steve,
                            >
                            > On Mar 13, 2013, at 10:19 AM, <steveropa@...> wrote:
                            >
                            > > I had the same experience, and it actually got me laid off. Our team was
                            > consistently producing zero bugs, or if something did escape, it was so
                            > small and taken care of so quickly that it didn�t register in some system.
                            > Our customers were delighted, but our organization felt that we weren�t
                            > devoting enough time to fixing bugs, thus we were doing something wrong.
                            > >
                            > > When the layoffs came, I was on the block since I clearly wasn't
                            > managing the team effectively anyway. I guess since I wasn�t really
                            > �managing� the team but supporting it, they were right.
                            >
                            >
                            > This sounds like a communication problem to me ... was it?
                            >

                            Or his organization was so dysfunctional he really won the layoff lottery.
                            --
                            --------------------------------------
                            Curtis Cooley
                            curtis@...


                            [Non-text portions of this message have been removed]
                          • Michal Svoboda
                            ... Hi, ... as if there were other kinds of problems. ;-)
                            Message 13 of 24 , Mar 13, 2013
                            View Source
                            • 0 Attachment
                              Ron Jeffries wrote:
                              > This sounds like a communication problem to me ... was it?

                              Hi,

                              ... as if there were other kinds of problems. ;-)
                            • Ron Jeffries
                              Hi Michal, ... Oh, there are. Like if the team doesn t know how to write code that works, and tests that demonstrate that fact. Of course one could argue that
                              Message 14 of 24 , Mar 13, 2013
                              View Source
                              • 0 Attachment
                                Hi Michal,

                                On Mar 13, 2013, at 1:47 PM, Michal Svoboda <pht@...> wrote:

                                > ... as if there were other kinds of problems. ;-)


                                Oh, there are. Like if the team doesn't know how to write code that works, and tests that demonstrate that fact.

                                Of course one could argue that someone needs to communicate to them how to do that � but surely no one here would try that quibble. :)

                                Ron Jeffries
                                www.XProgramming.com
                                If another does not intend offense, it is wrong for me to seek it;
                                if another does indeed intend offense, it is foolish for me to permit it.
                                -- Kelly Easterley



                                [Non-text portions of this message have been removed]
                              • Steve Smith
                                I m not sure who said it first (it wasn t me), but I like the quote: If you have a process that is producing defects, then you have a defective process.
                                Message 15 of 24 , Mar 13, 2013
                                View Source
                                • 0 Attachment
                                  I'm not sure who said it first (it wasn't me), but I like the quote:
                                  "If you have a process that is producing defects, then you have a defective
                                  process."

                                  Steve



                                  On Wed, Mar 13, 2013 at 6:35 AM, Ron Jeffries <ronjeffries@...> wrote:

                                  > **
                                  >
                                  >
                                  > Hello, John,
                                  >
                                  >
                                  > On Mar 12, 2013, at 11:47 PM, John Carter <john.carter@...> wrote:
                                  >
                                  > > a) The Obvious and most Desirable route is Magic Happens, and developers
                                  > > create so few defects there aren't any defects for the testers to find.
                                  > >
                                  > > b) The "lean manufacturing", less desirable, but still sane answer that
                                  > you
                                  > > balance the number of testers, new feature developers, and defect fixers
                                  > > until the rates of defect injection, discovery and fix are identical. (No
                                  > > queues)
                                  > >
                                  > > c) The even less desirable, but still vaguely sanish answer that when the
                                  > > sticky notes have covered the door... you start throwing away the least
                                  > > important (and rely on the tester's memory that we found that bug before,
                                  > > but threw it away).
                                  > >
                                  > > d) The totally unacceptable route that you have so few / so weak testers
                                  > > that despite an ever growing pool of defects, they aren't finding them.
                                  >
                                  > I have to say that I'm a bit surprised to see you asking this question.
                                  >
                                  > Alistair's point is that good teams don't have very many defects. Frankly
                                  > I don't see why they'd need a whole bloody door.
                                  >
                                  > The correct option is (a), but it's not done with magic, it's done by
                                  > being ****ing competent. Let's face it, if developers are creating defects,
                                  > they are to that extent incompetent.
                                  >
                                  > The notion included in (b) seems to think that only testers can find
                                  > defects and only "defect fixers" can fix them. XP and all Agile methods are
                                  > about cross-functional teams. The team tests, the team finds defects, the
                                  > team fixes them.
                                  >
                                  > How do they do that?
                                  >
                                  > Add testing skill to the development team. One way to do this is to merge
                                  > the existing testers right in. Clearly the team needs all the necessary
                                  > skills to develop each feature, yes? Well, if the features are shipping
                                  > with defects, then clearly the team needs more testing.
                                  > Use Acceptance Test-Driven Development. Each feature's description
                                  > includes defined and preferably automated tests (checks) of examples of
                                  > that feature's correct operation. Developers, not being stupid, do not pass
                                  > code on until it passes all these tests. See the "Three C's" notion. These
                                  > are "Customer Tests".
                                  > Analyze every defect. When defects arise, figure out how each one
                                  > occurred. Since you are doing Acceptance Test-Driven Development, it is
                                  > evident that there is at least one missing test. Write that check, plus all
                                  > the others that occur to you in light of the missing one. Beef up your
                                  > overall approach to ATDD, improving how you define new tests. Retrofit old
                                  > tests as indicated.
                                  > Use Test-Driven Development. Developers write no line of code until they
                                  > have a failing test asking for that very line of code. These are
                                  > "Programmer Tests", sometimes called unit tests. As in step 3 above, when
                                  > defects show up, they also indicate that TDD tests are missing. Write
                                  > those, learn from it.
                                  >
                                  > "Won't that take forever, all that testing? We'll never get done!"
                                  >
                                  > You'll never get done now! Your god-blessed bug database is filling up and
                                  > your thrice-blessed programmers are piling more dead code on top of the
                                  > existing dead code. When were you planning to fix all these bugs, in
                                  > Fixtober, Bugvember, and Defectcember? I'm sorry, those months were
                                  > cancelled. Better fix them now.
                                  >
                                  > It takes less time to prevent a defect than to fix it. So invest the time
                                  > to write the tests before you code, and don't stop coding until the tests
                                  > work. Voila, bug production drops by an order of magnitude, even if you
                                  > completely suck at writing tests. If you get good at it, and with all that
                                  > practice you will get good at it, and it'll drop by another order of
                                  > magnitude.
                                  >
                                  > In short, XP.
                                  >
                                  > This topic, and the answer, has been around a long time. A few articles
                                  > relating to this subject:
                                  >
                                  > http://xprogramming.com/articles/which-end-of-the-horse/
                                  > http://xprogramming.com/articles/expcardconversationconfirmation/
                                  > http://xprogramming.com/articles/where-can-we-reduce-quality/
                                  > http://xprogramming.com/blog/discovering-essential-technical-practices/
                                  > http://xprogramming.com/articles/manual-testing-does-exist-and-it-is-bad/
                                  > http://xprogramming.com/articles/kate-oneal-handling-defects/
                                  >
                                  > Ron Jeffries
                                  > www.XProgramming.com
                                  > Perfectionism is the voice of the oppressor -- Anne Lamott
                                  >
                                  >
                                  > [Non-text portions of this message have been removed]
                                  >
                                  >
                                  >



                                  --
                                  Steve Smith
                                  http://Ardalis.com/
                                  http://twitter.com/ardalis


                                  [Non-text portions of this message have been removed]
                                • Keith Ray
                                  Can I quote you on that ? (Twitter) C. Keith Ray http://agilesolutionspace.blogspot.com/ twitter: @ckeithray
                                  Message 16 of 24 , Mar 13, 2013
                                  View Source
                                  • 0 Attachment
                                    Can I quote you on that ? (Twitter)

                                    C. Keith Ray
                                    http://agilesolutionspace.blogspot.com/
                                    twitter: @ckeithray


                                    On Mar 13, 2013, at 11:14 AM, Steve Smith <ssmith.lists@...> wrote:

                                    > I'm not sure who said it first (it wasn't me), but I like the quote:
                                    > "If you have a process that is producing defects, then you have a defective
                                    > process."
                                    >
                                    > Steve
                                    >
                                    >
                                    >
                                    > On Wed, Mar 13, 2013 at 6:35 AM, Ron Jeffries <ronjeffries@...> wrote:
                                    >
                                    >> **
                                    >>
                                    >>
                                    >> Hello, John,
                                    >>
                                    >>
                                    >> On Mar 12, 2013, at 11:47 PM, John Carter <john.carter@...> wrote:
                                    >>
                                    >>> a) The Obvious and most Desirable route is Magic Happens, and developers
                                    >>> create so few defects there aren't any defects for the testers to find.
                                    >>>
                                    >>> b) The "lean manufacturing", less desirable, but still sane answer that
                                    >> you
                                    >>> balance the number of testers, new feature developers, and defect fixers
                                    >>> until the rates of defect injection, discovery and fix are identical. (No
                                    >>> queues)
                                    >>>
                                    >>> c) The even less desirable, but still vaguely sanish answer that when the
                                    >>> sticky notes have covered the door... you start throwing away the least
                                    >>> important (and rely on the tester's memory that we found that bug before,
                                    >>> but threw it away).
                                    >>>
                                    >>> d) The totally unacceptable route that you have so few / so weak testers
                                    >>> that despite an ever growing pool of defects, they aren't finding them.
                                    >>
                                    >> I have to say that I'm a bit surprised to see you asking this question.
                                    >>
                                    >> Alistair's point is that good teams don't have very many defects. Frankly
                                    >> I don't see why they'd need a whole bloody door.
                                    >>
                                    >> The correct option is (a), but it's not done with magic, it's done by
                                    >> being ****ing competent. Let's face it, if developers are creating defects,
                                    >> they are to that extent incompetent.
                                    >>
                                    >> The notion included in (b) seems to think that only testers can find
                                    >> defects and only "defect fixers" can fix them. XP and all Agile methods are
                                    >> about cross-functional teams. The team tests, the team finds defects, the
                                    >> team fixes them.
                                    >>
                                    >> How do they do that?
                                    >>
                                    >> Add testing skill to the development team. One way to do this is to merge
                                    >> the existing testers right in. Clearly the team needs all the necessary
                                    >> skills to develop each feature, yes? Well, if the features are shipping
                                    >> with defects, then clearly the team needs more testing.
                                    >> Use Acceptance Test-Driven Development. Each feature's description
                                    >> includes defined and preferably automated tests (checks) of examples of
                                    >> that feature's correct operation. Developers, not being stupid, do not pass
                                    >> code on until it passes all these tests. See the "Three C's" notion. These
                                    >> are "Customer Tests".
                                    >> Analyze every defect. When defects arise, figure out how each one
                                    >> occurred. Since you are doing Acceptance Test-Driven Development, it is
                                    >> evident that there is at least one missing test. Write that check, plus all
                                    >> the others that occur to you in light of the missing one. Beef up your
                                    >> overall approach to ATDD, improving how you define new tests. Retrofit old
                                    >> tests as indicated.
                                    >> Use Test-Driven Development. Developers write no line of code until they
                                    >> have a failing test asking for that very line of code. These are
                                    >> "Programmer Tests", sometimes called unit tests. As in step 3 above, when
                                    >> defects show up, they also indicate that TDD tests are missing. Write
                                    >> those, learn from it.
                                    >>
                                    >> "Won't that take forever, all that testing? We'll never get done!"
                                    >>
                                    >> You'll never get done now! Your god-blessed bug database is filling up and
                                    >> your thrice-blessed programmers are piling more dead code on top of the
                                    >> existing dead code. When were you planning to fix all these bugs, in
                                    >> Fixtober, Bugvember, and Defectcember? I'm sorry, those months were
                                    >> cancelled. Better fix them now.
                                    >>
                                    >> It takes less time to prevent a defect than to fix it. So invest the time
                                    >> to write the tests before you code, and don't stop coding until the tests
                                    >> work. Voila, bug production drops by an order of magnitude, even if you
                                    >> completely suck at writing tests. If you get good at it, and with all that
                                    >> practice you will get good at it, and it'll drop by another order of
                                    >> magnitude.
                                    >>
                                    >> In short, XP.
                                    >>
                                    >> This topic, and the answer, has been around a long time. A few articles
                                    >> relating to this subject:
                                    >>
                                    >> http://xprogramming.com/articles/which-end-of-the-horse/
                                    >> http://xprogramming.com/articles/expcardconversationconfirmation/
                                    >> http://xprogramming.com/articles/where-can-we-reduce-quality/
                                    >> http://xprogramming.com/blog/discovering-essential-technical-practices/
                                    >> http://xprogramming.com/articles/manual-testing-does-exist-and-it-is-bad/
                                    >> http://xprogramming.com/articles/kate-oneal-handling-defects/
                                    >>
                                    >> Ron Jeffries
                                    >> www.XProgramming.com
                                    >> Perfectionism is the voice of the oppressor -- Anne Lamott
                                    >>
                                    >>
                                    >> [Non-text portions of this message have been removed]
                                    >
                                    >
                                    >
                                    > --
                                    > Steve Smith
                                    > http://Ardalis.com/
                                    > http://twitter.com/ardalis
                                    >
                                    >
                                    > [Non-text portions of this message have been removed]
                                    >
                                    >
                                    >
                                    > ------------------------------------
                                    >
                                    > To Post a message, send it to: extremeprogramming@...
                                    >
                                    > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                    >
                                    > ad-free courtesy of objectmentor.comYahoo! Groups Links
                                    >
                                    >
                                    >
                                  • Steven Gordon
                                    ... A dangerous quote - it is people who do or do not produce defects. Processes can only help or hinder. A process that attempts to make it impossible for
                                    Message 17 of 24 , Mar 13, 2013
                                    View Source
                                    • 0 Attachment
                                      On Wed, Mar 13, 2013 at 11:14 AM, Steve Smith <ssmith.lists@...>wrote:

                                      > I'm not sure who said it first (it wasn't me), but I like the quote:
                                      > "If you have a process that is producing defects, then you have a defective
                                      > process."
                                      >
                                      > Steve
                                      >
                                      >
                                      A dangerous quote - it is people who do or do not produce defects.
                                      Processes can only help or hinder.

                                      A process that attempts to make it impossible for people to produce defects
                                      would be too prescriptive to be efficient or to produce learning or
                                      innovation. We would all much prefer a process that facilitates people
                                      learning to get better, but then such a process would allow defects along
                                      the way.

                                      SteveG


                                      [Non-text portions of this message have been removed]
                                    • Ron Jeffries
                                      Hi Steven, ... Could you perhaps phrase this idea in such a way as to do two things that this does not: First, offer advice on what one might do, rather than
                                      Message 18 of 24 , Mar 13, 2013
                                      View Source
                                      • 0 Attachment
                                        Hi Steven,

                                        On Mar 13, 2013, at 3:16 PM, Steven Gordon <sgordonphd@...> wrote:

                                        > A process that attempts to make it impossible for people to produce defects
                                        > would be too prescriptive to be efficient or to produce learning or
                                        > innovation. We would all much prefer a process that facilitates people
                                        > learning to get better, but then such a process would allow defects along
                                        > the way.


                                        Could you perhaps phrase this idea in such a way as to do two things that this does not:

                                        First, offer advice on what one might do, rather than on what one ought not do, and, second, offer advice that tends to lead to a continuing reduction of defects?

                                        Ron Jeffries
                                        www.XProgramming.com
                                        I have two cats, and a big house full of cat stuff.
                                        The cats fight and divide up the house, messing up their own lives.
                                        Nice work cats.
                                        Meow.



                                        [Non-text portions of this message have been removed]
                                      • John Carter
                                        ... Problems found later became a (possibly high priority) story. That is effectively, although perhaps not consciously, the lean manufacturing route. ie.
                                        Message 19 of 24 , Mar 13, 2013
                                        View Source
                                        • 0 Attachment
                                          On Wed, Mar 13, 2013 at 5:07 PM, Charlie Poole <charliepoole@...>wrote:

                                          > Problems found when a story was initially believed to be finished either
                                          > meant the story wasn't finished or that a new story had to be written.
                                          >
                                          Problems found later became a (possibly high priority) story.


                                          That is effectively, although perhaps not consciously, the "lean
                                          manufacturing" route.

                                          ie. Throttle the rate of defect injection / increase defect fix to match
                                          that of defect discovery.

                                          ie. No queues.


                                          > > b) The "lean manufacturing", less desirable, but still sane answer that
                                          > you
                                          > > balance the number of testers, new feature developers, and defect fixers
                                          > > until the rates of defect injection, discovery and fix are identical. (No
                                          > > queues)
                                          >




                                          --
                                          John Carter Phone : (64)(3) 358 6639
                                          Tait Electronics Fax : (64)(3) 359 4632
                                          PO Box 1645 Christchurch Email : john.carter@...
                                          New Zealand

                                          --

                                          ------------------------------
                                          This email, including any attachments, is only for the intended recipient.
                                          It is subject to copyright, is confidential and may be the subject of legal
                                          or other privilege, none of which is waived or lost by reason of this
                                          transmission.
                                          If you are not an intended recipient, you may not use, disseminate,
                                          distribute or reproduce such email, any attachments, or any part thereof.
                                          If you have received a message in error, please notify the sender
                                          immediately and erase all copies of the message and any attachments.
                                          Unfortunately, we cannot warrant that the email has not been altered or
                                          corrupted during transmission nor can we guarantee that any email or any
                                          attachments are free from computer viruses or other conditions which may
                                          damage or interfere with recipient data, hardware or software. The
                                          recipient relies upon its own procedures and assumes all risk of use and of
                                          opening any attachments.
                                          ------------------------------


                                          [Non-text portions of this message have been removed]
                                        • Steve Smith
                                          One might try to create an uber-prescriptive process that makes defects impossible - and it might be successful, in that it might prevent any work at all from
                                          Message 20 of 24 , Mar 13, 2013
                                          View Source
                                          • 0 Attachment
                                            One might try to create an uber-prescriptive process that makes defects
                                            impossible - and it might be successful, in that it might prevent any work
                                            at all from getting done (but hey, zero bugs!). I think we both agree that
                                            a more appropriate process is one that is more flexible and adaptable and
                                            lets the people involved (whom I agree are the most important part) do the
                                            right things to prevent shipping defects. Of course mistakes and learning
                                            will happen - the process should simply encourage this kind of learning and
                                            improving the process to prevent defects from shipping (and to prevent
                                            known defects from recurring).

                                            Steve



                                            On Wed, Mar 13, 2013 at 3:16 PM, Steven Gordon <sgordonphd@...> wrote:

                                            > **
                                            >
                                            >
                                            > On Wed, Mar 13, 2013 at 11:14 AM, Steve Smith <ssmith.lists@...
                                            > >wrote:
                                            >
                                            >
                                            > > I'm not sure who said it first (it wasn't me), but I like the quote:
                                            > > "If you have a process that is producing defects, then you have a
                                            > defective
                                            > > process."
                                            > >
                                            > > Steve
                                            > >
                                            > >
                                            > A dangerous quote - it is people who do or do not produce defects.
                                            > Processes can only help or hinder.
                                            >
                                            > A process that attempts to make it impossible for people to produce defects
                                            > would be too prescriptive to be efficient or to produce learning or
                                            > innovation. We would all much prefer a process that facilitates people
                                            > learning to get better, but then such a process would allow defects along
                                            > the way.
                                            >
                                            > SteveG
                                            >
                                            >
                                            > [Non-text portions of this message have been removed]
                                            >
                                            >
                                            >



                                            --
                                            Steve Smith
                                            http://Ardalis.com/
                                            http://twitter.com/ardalis


                                            [Non-text portions of this message have been removed]
                                          • Steve Smith
                                            Sure, I m @ardalis and I actually tweeted it myself right after posting this... :) ... -- Steve Smith http://Ardalis.com/ http://twitter.com/ardalis [Non-text
                                            Message 21 of 24 , Mar 13, 2013
                                            View Source
                                            • 0 Attachment
                                              Sure, I'm @ardalis and I actually tweeted it myself right after posting
                                              this... :)


                                              On Wed, Mar 13, 2013 at 2:28 PM, Keith Ray <keith.ray@...> wrote:

                                              > **
                                              >
                                              >
                                              > Can I quote you on that ? (Twitter)
                                              >
                                              > C. Keith Ray
                                              > http://agilesolutionspace.blogspot.com/
                                              > twitter: @ckeithray
                                              >
                                              >
                                              > On Mar 13, 2013, at 11:14 AM, Steve Smith <ssmith.lists@...> wrote:
                                              >
                                              > > I'm not sure who said it first (it wasn't me), but I like the quote:
                                              > > "If you have a process that is producing defects, then you have a
                                              > defective
                                              > > process."
                                              > >
                                              > > Steve
                                              > >
                                              > >
                                              > >
                                              > > On Wed, Mar 13, 2013 at 6:35 AM, Ron Jeffries <ronjeffries@...>
                                              > wrote:
                                              > >
                                              > >> **
                                              >
                                              > >>
                                              > >>
                                              > >> Hello, John,
                                              > >>
                                              > >>
                                              > >> On Mar 12, 2013, at 11:47 PM, John Carter <john.carter@...>
                                              > wrote:
                                              > >>
                                              > >>> a) The Obvious and most Desirable route is Magic Happens, and
                                              > developers
                                              > >>> create so few defects there aren't any defects for the testers to find.
                                              > >>>
                                              > >>> b) The "lean manufacturing", less desirable, but still sane answer that
                                              > >> you
                                              > >>> balance the number of testers, new feature developers, and defect
                                              > fixers
                                              > >>> until the rates of defect injection, discovery and fix are identical.
                                              > (No
                                              > >>> queues)
                                              > >>>
                                              > >>> c) The even less desirable, but still vaguely sanish answer that when
                                              > the
                                              > >>> sticky notes have covered the door... you start throwing away the least
                                              > >>> important (and rely on the tester's memory that we found that bug
                                              > before,
                                              > >>> but threw it away).
                                              > >>>
                                              > >>> d) The totally unacceptable route that you have so few / so weak
                                              > testers
                                              > >>> that despite an ever growing pool of defects, they aren't finding them.
                                              > >>
                                              > >> I have to say that I'm a bit surprised to see you asking this question.
                                              > >>
                                              > >> Alistair's point is that good teams don't have very many defects.
                                              > Frankly
                                              > >> I don't see why they'd need a whole bloody door.
                                              > >>
                                              > >> The correct option is (a), but it's not done with magic, it's done by
                                              > >> being ****ing competent. Let's face it, if developers are creating
                                              > defects,
                                              > >> they are to that extent incompetent.
                                              > >>
                                              > >> The notion included in (b) seems to think that only testers can find
                                              > >> defects and only "defect fixers" can fix them. XP and all Agile methods
                                              > are
                                              > >> about cross-functional teams. The team tests, the team finds defects,
                                              > the
                                              > >> team fixes them.
                                              > >>
                                              > >> How do they do that?
                                              > >>
                                              > >> Add testing skill to the development team. One way to do this is to
                                              > merge
                                              > >> the existing testers right in. Clearly the team needs all the necessary
                                              > >> skills to develop each feature, yes? Well, if the features are shipping
                                              > >> with defects, then clearly the team needs more testing.
                                              > >> Use Acceptance Test-Driven Development. Each feature's description
                                              > >> includes defined and preferably automated tests (checks) of examples of
                                              > >> that feature's correct operation. Developers, not being stupid, do not
                                              > pass
                                              > >> code on until it passes all these tests. See the "Three C's" notion.
                                              > These
                                              > >> are "Customer Tests".
                                              > >> Analyze every defect. When defects arise, figure out how each one
                                              > >> occurred. Since you are doing Acceptance Test-Driven Development, it is
                                              > >> evident that there is at least one missing test. Write that check, plus
                                              > all
                                              > >> the others that occur to you in light of the missing one. Beef up your
                                              > >> overall approach to ATDD, improving how you define new tests. Retrofit
                                              > old
                                              > >> tests as indicated.
                                              > >> Use Test-Driven Development. Developers write no line of code until they
                                              > >> have a failing test asking for that very line of code. These are
                                              > >> "Programmer Tests", sometimes called unit tests. As in step 3 above,
                                              > when
                                              > >> defects show up, they also indicate that TDD tests are missing. Write
                                              > >> those, learn from it.
                                              > >>
                                              > >> "Won't that take forever, all that testing? We'll never get done!"
                                              > >>
                                              > >> You'll never get done now! Your god-blessed bug database is filling up
                                              > and
                                              > >> your thrice-blessed programmers are piling more dead code on top of the
                                              > >> existing dead code. When were you planning to fix all these bugs, in
                                              > >> Fixtober, Bugvember, and Defectcember? I'm sorry, those months were
                                              > >> cancelled. Better fix them now.
                                              > >>
                                              > >> It takes less time to prevent a defect than to fix it. So invest the
                                              > time
                                              > >> to write the tests before you code, and don't stop coding until the
                                              > tests
                                              > >> work. Voila, bug production drops by an order of magnitude, even if you
                                              > >> completely suck at writing tests. If you get good at it, and with all
                                              > that
                                              > >> practice you will get good at it, and it'll drop by another order of
                                              > >> magnitude.
                                              > >>
                                              > >> In short, XP.
                                              > >>
                                              > >> This topic, and the answer, has been around a long time. A few articles
                                              > >> relating to this subject:
                                              > >>
                                              > >> http://xprogramming.com/articles/which-end-of-the-horse/
                                              > >> http://xprogramming.com/articles/expcardconversationconfirmation/
                                              > >> http://xprogramming.com/articles/where-can-we-reduce-quality/
                                              > >> http://xprogramming.com/blog/discovering-essential-technical-practices/
                                              > >>
                                              > http://xprogramming.com/articles/manual-testing-does-exist-and-it-is-bad/
                                              > >> http://xprogramming.com/articles/kate-oneal-handling-defects/
                                              > >>
                                              > >> Ron Jeffries
                                              > >> www.XProgramming.com
                                              > >> Perfectionism is the voice of the oppressor -- Anne Lamott
                                              > >>
                                              > >>
                                              > >> [Non-text portions of this message have been removed]
                                              > >
                                              > >
                                              > >
                                              > > --
                                              > > Steve Smith
                                              > > http://Ardalis.com/
                                              > > http://twitter.com/ardalis
                                              > >
                                              > >
                                              > > [Non-text portions of this message have been removed]
                                              > >
                                              > >
                                              > >
                                              > > ------------------------------------
                                              >
                                              > >
                                              > > To Post a message, send it to: extremeprogramming@...
                                              > >
                                              > > To Unsubscribe, send a blank message to:
                                              > extremeprogramming-unsubscribe@...
                                              > >
                                              > > ad-free courtesy of objectmentor.comYahoo! Groups Links
                                              > >
                                              > >
                                              > >
                                              >
                                              >
                                              >



                                              --
                                              Steve Smith
                                              http://Ardalis.com/
                                              http://twitter.com/ardalis


                                              [Non-text portions of this message have been removed]
                                            • Steven Gordon
                                              ... I would agree with offering advice, but I would prefer not to prescribe it. In practice, teams generally follow said advice much better if they own it. ...
                                              Message 22 of 24 , Mar 13, 2013
                                              View Source
                                              • 0 Attachment
                                                On Wed, Mar 13, 2013 at 12:37 PM, Ron Jeffries <ronjeffries@...> wrote:

                                                > **
                                                >
                                                >
                                                > Hi Steven,
                                                >
                                                >
                                                > On Mar 13, 2013, at 3:16 PM, Steven Gordon <sgordonphd@...> wrote:
                                                >
                                                > > A process that attempts to make it impossible for people to produce
                                                > defects
                                                > > would be too prescriptive to be efficient or to produce learning or
                                                > > innovation. We would all much prefer a process that facilitates people
                                                > > learning to get better, but then such a process would allow defects along
                                                > > the way.
                                                >
                                                > Could you perhaps phrase this idea in such a way as to do two things that
                                                > this does not:
                                                >
                                                > First, offer advice on what one might do, rather than on what one ought
                                                > not do, and, second, offer advice that tends to lead to a continuing
                                                > reduction of defects?
                                                >

                                                I would agree with offering advice, but I would prefer not to prescribe it.
                                                In practice, teams generally follow said advice much better if they own it.


                                                >
                                                > Ron Jeffries
                                                > www.XProgramming.com
                                                > I have two cats, and a big house full of cat stuff.
                                                > The cats fight and divide up the house, messing up their own lives.
                                                > Nice work cats.
                                                > Meow.
                                                >
                                                >
                                                >


                                                [Non-text portions of this message have been removed]
                                              • Michal Svoboda
                                                ... Fair enough. But I would say that s a natural occurrence, or imperfection if you will. No-one is born with coding skills, we all learn. Now if or how big
                                                Message 23 of 24 , Mar 13, 2013
                                                View Source
                                                • 0 Attachment
                                                  Ron Jeffries wrote:
                                                  > > ... as if there were other kinds of problems. ;-)
                                                  > Oh, there are. Like if the team doesn't know how to write code that
                                                  > works, and tests that demonstrate that fact.

                                                  Fair enough. But I would say that's a natural occurrence, or imperfection
                                                  if you will. No-one is born with coding skills, we all learn.

                                                  Now if or how big this is a problem, depends on communication. If I don't
                                                  talk about it or they don't listen, then problem grows. So I observe that
                                                  problems in communication are able to create proportionally greater
                                                  disasters than anything else.

                                                  Michal Svoboda
                                                • Kay A Pentecost
                                                  +1 ... magic.
                                                  Message 24 of 24 , Mar 14, 2013
                                                  View Source
                                                  • 0 Attachment
                                                    +1

                                                    > -----Original Message-----
                                                    > From: extremeprogramming@yahoogroups.com
                                                    > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Charlie
                                                    > Poole
                                                    > Sent: Wednesday, March 13, 2013 1:58 AM
                                                    > To: extremeprogramming@yahoogroups.com
                                                    > Subject: Re: [XP] Back of the Door Sticky Note Issue Tracking.
                                                    >
                                                    > Hi George,
                                                    >
                                                    > Maybe we should just say "Yes, we cheated. And we figured out a way to
                                                    > keep cheating, so that tests keep passing. Do you want us to stop?"
                                                    >
                                                    > Charlie
                                                    >
                                                    >
                                                    > On Tue, Mar 12, 2013 at 9:52 PM, George Dinwiddie
                                                    > <lists@...>wrote:
                                                    >
                                                    > > **
                                                    > >
                                                    > >
                                                    > > John,
                                                    > >
                                                    > > On 3/13/13 12:42 AM, John Carter wrote:
                                                    > > > On Wed, Mar 13, 2013 at 5:20 PM, George Dinwiddie
                                                    > > > <lists@...>wrote:
                                                    > > >
                                                    > > >> I've seen a team of ordinary programmers reach the state of
                                                    > > >> frequently shipping zero bugs (even measured after deployment), and
                                                    > > >> quickly taking care of the ones that escaped an iteration. It's not
                                                    magic.
                                                    > > >>
                                                    > > >
                                                    > > > This is the Very Interesting Answer which I would like to bring home
                                                    > > > to
                                                    > > the
                                                    > > > rest of the company....
                                                    > > >
                                                    > > > My colleagues are quite comfortable with the "lean manufacturing" no
                                                    > > queues
                                                    > > > answer, but plain flat out don't believe the "No Defect Magic" answer.
                                                    > > >
                                                    > > > So I'm looking for data / evidence / stories / books / papers to
                                                    > > > convince them that we could do better.
                                                    > >
                                                    > > Do you think that will convince them?
                                                    > >
                                                    > > It didn't even convince the organization around them. The comment on
                                                    > > their first release, when 92% of the release test scripts passed on
                                                    > > the first attempt, was "they cheated; they tested ahead of time." I
                                                    > > think it was the second or third release when they hit 100%.
                                                    > >
                                                    > > Yes, they tested, not always automated. They also had a sign on the
                                                    > > wall that said "Zero bugs, the new normal."
                                                    > >
                                                    > > - George
                                                    > >
                                                    > > --
                                                    > > ----------------------------------------------------------
                                                    > > * George Dinwiddie * http://blog.gdinwiddie.com Software Development
                                                    > > http://www.idiacomputing.com Consultant and Coach
                                                    > > http://www.agilemaryland.org
                                                    > > ----------------------------------------------------------
                                                    > >
                                                    > >
                                                    > >
                                                    >
                                                    >
                                                    > [Non-text portions of this message have been removed]
                                                    >
                                                    >
                                                    >
                                                    > ------------------------------------
                                                    >
                                                    > To Post a message, send it to: extremeprogramming@...
                                                    >
                                                    > To Unsubscribe, send a blank message to: extremeprogramming-
                                                    > unsubscribe@...
                                                    >
                                                    > ad-free courtesy of objectmentor.comYahoo! Groups Links
                                                    >
                                                    >
                                                    >
                                                  Your message has been successfully submitted and would be delivered to recipients shortly.