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

Cargo Cult

Expand Messages
  • Ron Jeffries
    Matt Heusser has been writing some provocative notes on the agile-testing list. I thought I d take one of those as my text today. I m very interested in
    Message 1 of 54 , May 12 8:01 AM
      Matt Heusser has been writing some provocative notes on the
      agile-testing list. I thought I'd take one of those as my text

      I'm very interested in discussion and feedback on this. I've been
      observing what I'll talk about here for a long time.

      He wrote:

      > If anyone is interested in the long version of this discussion, the
      > definitive work is Steve McConnell's "Cargo Cult Software
      > Engineering", available on-line here:
      > http://www.stevemcconnell.com/ieeesoftware/eic10.htm

      I don't agree with that whole article but I'd suggest giving it an
      open-minded read. I look at it in this light:

      McConnell writes about process-imposter and commitment-imposter
      organizations, and points out that they are similar in that each
      group does poorly because they don't fully understand what they are
      doing, whether it is following a process or trying to gain a
      hard-working commitment. He says:

      Cargo cult software engineering is easy to identify. Cargo cult
      software engineers justify their practices by saying, "We’ve
      always done it this way in the past," or "our company standards
      require us to do it this way"—even when those ways make no sense.
      They refuse to acknowledge the tradeoffs involved in either
      process-oriented or commitment-oriented development. Both have
      strengths and weaknesses. When presented with more effective, new
      practices, cargo cult software engineers prefer to stay in their
      wooden huts of familiar, comfortable and-not-necessarily-effective
      work habits. "Doing the same thing again and again and expecting
      different results is a sign of insanity," the old saying goes.
      It’s also a sign of cargo cult software engineering.

      Now McConnell moves from these observations to a call for increasing
      competence through education and training. He points out -- and I
      agree -- that more competent people are more likely to succeed.

      But while I agree with him on that, my own concerns are a bit
      different. Over the past decade+ of doing this, I've seen a lot of
      teams who plateau, never attaining the level that they could. And
      that's not just my judgment of how good they could be, but their
      own, and their management's. I've seen a lot of teams reach a really
      good level of performance, and then fall away from the behaviors
      that got them there. Even worse, I've seen teams who seem to be
      sticking to the practices that got them there, but nonetheless do
      not prosper.

      I am not entirely sure why this happens, and suppose that different
      teams have different reasons. But here are some patterns I've

      1. The team does its practices as if they were some kind of ritual
      that is followed for its own sake. Perhaps they have never
      understood why they do them, or perhaps they have forgotten.

      2. The team does its practices because it has been told to do the
      practices. "That's just the way we work here."

      3. The team is under pressure, imposed by management, or
      self-imposed from a feeling of urgency, which causes them to
      revert to old habits, or to rush the hidden aspects of their work.

      Now at first there seems to be no common element here. But I think
      there are one, perhaps two.

      First, the team may not be doing its practices mindfully. If we want
      to increase our skill, we have to think about what we are doing. We
      have to do a thing, experience the results, and reflect on them.
      This is the Feedback value of XP in action.

      Second, the team may not be continually varying their practices and
      observing what happens. When we drive, we are always adjusting the
      wheel based on what we see. When we drive for performance, we change
      our route around the track in small ways, to find what works best.
      Again Feedback in action.

      So I hypothesize, based on a lot of observation, that teams that
      plateau or fall back have not been paying attention to what happens
      as their practices vary. There are a number of reasons why they
      might not do that. I'll list a few here:

      The practices may not be their own but imposed through fiat or

      The practices may not vary, because of habit or external

      The practices may be seen as not important, owing to louder
      voices in the organization, who may be calling for more features
      and harder work.

      It would be necessary to look at a team that wasn't improving, and
      to assess openly and honestly what might be getting in their way. It
      seems likely that every one of the items above would be happening
      with the best of will. Unfortunately, good will is not enough to
      provide good results.

      Introspection might help. Help from outside might be of value.
      Ultimately the team has to examine itself with a cool head and
      recognize that they need to change, no matter how good their will
      may be, and no matter how well they believe things should work.

      To improve, we have to change.

      Ron Jeffries
      In times of stress, I like to turn to the wisdom of my Portuguese waitress,
      who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
      -- after Mark Vaughn, Autoweek.
    • Gary Brown
      ... From: Ron Jeffries To: Sent: Saturday, May 24, 2008 7:39 AM Subject: Re: [XP] Cargo
      Message 54 of 54 , May 24 6:47 AM
        ----- Original Message -----
        From: "Ron Jeffries" <ronjeffries@...>
        To: <extremeprogramming@yahoogroups.com>
        Sent: Saturday, May 24, 2008 7:39 AM
        Subject: Re: [XP] Cargo Cult

        > Hello, Steven. On Friday, May 23, 2008, at 7:49:04 PM, you wrote:
        >> It seems to me that it is quite possible to continuously improve the
        >> process as well as the code without improving as individuals. This is
        >> where expecting that the individuals should devote tangible effort at
        >> improving their skills seems to be unnecessarily intrusive, as long as
        >> the value of what is being produced continues to improve (unless those
        >> who have that expectation are paying for time that is supposed to be
        >> devoted to individual improvement.)
        > Well, and in Gary's company's case, for example, I believe that they
        > /are/ paying for time that is supposed to be devoted to individual
        > improvement. OTOH, I'm not sure just what the guidelines are for
        > what one can work on in that interval.

        Yes, every Friday afternoon is designated as PDT, right after the company
        provided Friday Lunch. 8^) The guidelines for PDT activities are simple,
        anything that helps you to become a better developer, anything that helps
        your team, or anything that helps the company. We have at least a dozon
        copies of every agile and OO software development book available, access to
        IL's eLearning, plus books on Java, web applications, Oracle, etc. If you
        want a work related book that we don't have, all you have to do is ask.

      Your message has been successfully submitted and would be delivered to recipients shortly.