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

to fix or not to fix

Expand Messages
  • D. André Dhondt
    In a recent blog entry by Kent Beck ( ... is key and the half-life of code is short, ... follow is to create as much value with my skills and talent as I can.
    Message 1 of 33 , Aug 6, 2009
    • 0 Attachment
      In a recent blog entry by Kent Beck (
      http://www.threeriversinstitute.org/blog/?p=321), he suggests that:
      >In an environment of great uncertainty and minimal resources, when latency
      is key and the half-life of code is short,
      > that means testing less and carrying defects.... The higher principle I
      follow is to create as much value with my skills and talent as I can.

      I'd like to discuss this a bit, because I think that these are words that
      chip away at what I hold dear--the *extreme* nature of XP. We have very few
      rules, but the ones we have, I try to follow without exception. Further, I
      think people could easily take these words out of context and fall into a
      'throw-it-over-the-wall' syndrome.

      The story Beck tells is about how context influences the way we develop. If
      we're in a stable part of the project, we are better off staying in Defect
      Zero zone. If we're in the beginning (of a startup or, as he's argued
      previously, in any project launch), then it's more important to get feedback
      from the real customer, so quality can drop. In this story, he was
      developing a web application, but focussed only on supporting one browser
      (Firefox), that is, he explains that he tolerated the crashes in other
      browsers.

      OK, so here's where I have a problem. I thought that our community has
      argued for years that the classic tradeoff triangle should not be
      resources-schedule-quality, but resources-schedule-scope. So if we have an
      application that works for one browser, but not others, that's not a
      bug--it's a conscious limitation on scope. I don't want to question my
      values regarding Defect Zero! I'm fine with releasing code with a clear
      explanation of what scenarios we expect it will work in, but to "carry
      defects" is different.

      Let me be clear--I don't think that Beck has actually compromised his
      principles. I think he's still doing TDD, keeping high quality, etc. I
      just think his hind-sight description of what's going on is using an archaic
      version of the trade off triangle. I agree that there should be a
      difference in how we handle scope in the runway phase of a project, that at
      this phase we don't need robustness, but we need end-to-end, concept-to-cash
      feedback from paying customers. It's appropriate to capitalize on the
      Pareto principle (80% value comes from 20% of the work). Then, when the
      project is mature, it's fine to make it more robust.

      Am I being too naive/idealist? Or unduly concerned with semantics
      (quality~scope)?


      --
      D. André Dhondt

      Support low-cost conferences -- http://agiletour.org/


      [Non-text portions of this message have been removed]
    • D. André Dhondt
      ... is listening and... does not hear what you think you said. Agreed... you folk are my mentors, so please don t make such confusing statments. Please do
      Message 33 of 33 , Aug 7, 2009
      • 0 Attachment
        >[if you say] "It is possible to go faster by cutting quality", the world
        is >listening and... does not hear what you think you said.
        Agreed... you folk are my mentors, so please don't make such confusing
        statments. Please do keep telling us your stories about tradeoffs, hard
        judgement calls, your successes and failures. I am listening, and trying to
        make sense of it all...

        --
        D. André Dhondt
        http://dhondtsayitsagile.blogspot.com/

        Support low-cost conferences -- http://agiletour.org/


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.