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

Re: [XP] Back of the Door Sticky Note Issue Tracking.

Expand Messages
  • 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 1 of 24 , Mar 13, 2013
    • 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 2 of 24 , Mar 13, 2013
      • 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 3 of 24 , Mar 13, 2013
        • 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 4 of 24 , Mar 14, 2013
          • 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.