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

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

Expand Messages
  • Steve Smith
    Mar 13 1:21 PM
    • 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]
    • Show all 24 messages in this topic