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

Re: [XP] Automated Testing Root Causes

Expand Messages
  • Tim Ottinger
    ... You did, but not in any troublesome way. For instance, the set of questions below are questions you answered, but I intended them as questions that remain
    Message 1 of 11 , Oct 28, 2008
    • 0 Attachment
      > Hi Tim and Jeff,
      > Thanks for your thoughts. Apologies if I have misunderstood you.

      You did, but not in any troublesome way. For instance, the set
      of questions below are questions you answered, but I intended them
      as questions that remain in the search for "Root Causes".

      > >> Why is the team out of rhythm?
      > >> Why is the code designed poorly?
      > >> Why do the tests tend to come out with this poor design?
      > >> Why don't people communicate?

      I was merely indicating that these things were also (at least
      potentially) symptoms, and had root causes that were worth

      > In my view none of these questions or answers are as useful as:
      > "what can we do right now to make rhythm, production code, test code
      > and communication a little better by the end of today than it was
      > yesterday?"

      We're agreed on this. But better yet is "what can we do to make next
      month better than this month", or s/month/year/g, whatever is the
      longest term that does not require you to guess or plan things that
      are outside your influence.

      > >> And yes, it also occurs to me that this team may benefit from
      > asking "Why?" another couple of times. ;->
      > At what point does further questioning "go meta" and cease to be of
      > pragmatic value to the team?

      We're talking about going more concrete, not more meta. The concern
      was that "poor design" and "poor rhythm" are too abstract.

      > My guess is that for different teams that point is different.
      > -- But when you address a root cause - you should no longer have the problem.

      We agree on this. We only haggle on whether your found a root cause
      or a common symptom.

      Ultimately, this comes down to the term "root cause" and whether you've
      found it or not. We would agree that treating symptoms and ignoring root
      causes is a sub-optimal choice, and that addressing a root cause will solve
      a problem, and that it is worthy and honorable work to trace back the
      surface symptoms to a deeper root cause.

      So we are closer in opinion than you might think.

      I think that you can learn an awful lot (and I mean awful in two ways)
      by watching the coping mechanisms that a team has developed, then peeling
      them away to get at the root causes. A team may do poor design because
      they don't have sufficient agreement on what constitutes "good". It could
      be a training issue. It may be that they've been under the gun to produce
      quick results rather than good ones. It may be that they don't value
      clean design. It could be that they've given up hope of being able to
      do good work because of constant interruption. It may be that the quality
      of design isn't their biggest problem at all. It may be that two of their
      strongest personalities have different opinions about design, and are duking
      it out in the code. Lean or TOC may have a good answer, or maybe study
      of patterns and principles. Maybe you have the wrong guys in charge.

      A layer or two deeper might give you the real root cause. I was merely
      recommending that you look for the a cause that is treatable, rather than
      an abstract symptom.

      And finally, pointedly, I suggest that your root causes are really just
      categories of failure types, rather than causes. You are going more meta
      rather than more specific.

      Not that there's anything wrong with that.
    Your message has been successfully submitted and would be delivered to recipients shortly.