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

Re: [XP] What is our craft?

Expand Messages
  • Ron Jeffries
    ... You seem to be offering an exclusive or here. If I can t write good code, any truthful metric will say I m doing poorly. If I can t write code quickly
    Message 1 of 47 , Oct 3, 2004
    • 0 Attachment
      On Sunday, October 3, 2004, at 10:24:28 AM, Ken Boucher wrote:

      > What seems to be a larger problem for teams that frequent this list:
      > the quality of their code or their ability to create a metric and
      > effectively present it to their customer/gold owner/hierarchy?

      You seem to be offering an exclusive "or" here.

      If I can't write good code, any truthful metric will say I'm doing poorly.
      If I can't write code quickly and well, my work is capable of being done by
      someone with all my skills plus just one, the ability to code quickly and
      well. (If that's just one skill, which of course it isn't.)

      > What's harder for these teams or the people here: Understanding what
      > to test, writing the test, or writing code that passes the test?

      Sometimes it's hard for me to understand what the customer wants. Sometimes
      it's hard to write the test. Sometimes it's hard to write the code. I'd
      like to be skilled in all those things and many others.

      > What percentage of people are on a team where their ability to
      > refactor is worse than their abilty to get the customer to understand
      > why refactoring is so important?

      Huh? I don't understand this question. However, I know that every customer
      will feel the pain of bad code sooner or later. He'll see his team bog
      down, or he'll see his program have high defect rates, or something.

      If the team can't refactor, permission won't help. If they can refactor
      well, they probably don't even need permission. I don't ask permission to
      use a for loop or a semicolon. Why would I ask permission to use reasonable
      names and avoid duplication?

      > I ask this because it's my perception that while some really smart
      > people are writing books on the latest theories on what makes for the
      > best code, that's not what the industry actually needs.

      The industry needs lots of things, and so do its practitioners. It seems
      very risky to me for an individual to focus only on one aspect of his
      craft. It seems even worse to deprecate the contributions that improved
      code can make to team spirit and productivity, just as it would be to
      deprecate good human relations.

      When it comes to improvement, wishing really won't make it so. We can
      blueprint that we'll have delighted customers, but that's not the end, it's
      the beginning. The focus on delight is supposed to cause us to reflect on
      how that might come about, and to learn and do the things that will make it
      happen.

      > However, my perception may be off by a mile. That's why I ask.

      The above is my view. Folks should hear what they want to hear, and
      disregard the rest. Or maybe what they don't want to hear. That could work
      too.

      Ron Jeffries
      www.XProgramming.com
      The practices are not the knowing: they are a path to the knowing.
    • Steven Gordon
      ... From: greeni_63 [mailto:greeni_63@yahoo.com] Sent: Mon 10/4/2004 10:48 AM To: extremeprogramming@yahoogroups.com Cc: Subject: [XP] Re: What is our craft?
      Message 47 of 47 , Oct 4, 2004
      • 0 Attachment
        -----Original Message-----
        From: greeni_63 [mailto:greeni_63@...]
        Sent: Mon 10/4/2004 10:48 AM
        To: extremeprogramming@yahoogroups.com
        Cc:
        Subject: [XP] Re: What is our craft? Quality and Metrics

        <snip>

        I also recall that Gerry Weinberg said that the customer will rarely
        know what they want until after we give them what they asked for.

        <snip>

        David Greenfield




        To make matters even more unstable, most of our customers are trying to use what we provide them to satisfy their customers, who also will not know what they want until after our customer gives them what they asked for. And many of those customers are trying to use what our customer gives them to satisfy their customers, who also do not yet know what they want. And so on.


        Then add on the perturbations caused by competitors who try to convince any of the customers in this chain that what they offer is what they really want.



        No matter what we produce, we will have to be able to adapt it to these layers of market forces to be long term successes.



        Steven Gordon

        http://sf.asu.edu/





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