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

[XP] Re: no excuses programming

Expand Messages
  • Dave Thomas
    ... I m interested in exploring this, because others have also mentioned the idea of aiming for the best code possible or somesuch. What are the criteria for
    Message 1 of 82 , Mar 1, 2000
      "Steve Metsker" <steve.metsker@...> writes:

      > One thing that might shed light on nx programming is the concept of
      > museum grade code. Sometimes I write code with the aspiration that
      > someday, a yellow bus will drive up, the kids will file out and
      > crowd around the code. The teacher says, "kids, *this* was some of
      > the best code written around the turn of the century." Of course, I
      > never achieve museum grade code, but I like aiming at it. This kind
      > of forced me into saying, "this is my best, no excuses". Like, say,
      > the Mona Lisa, museum grade code is not perfect, it is museum grade,
      > which comprehends the context of its composition. Anyhow, I think
      > museum grade code is worth aiming at, at least sometimes, and it has
      > prodded me into an nx attitude.

      I'm interested in exploring this, because others have also mentioned
      the idea of aiming for 'the best code possible' or somesuch.

      What are the criteria for measuring this?

      Say I have a one-off conversion of data from format A to format B. I
      hack up a 10 line Perl script which is ugly as sin but works a
      treat. Or I spend a couple of days polishing the ultimate in data
      conversion--code that's fit to be placed behind glass in a museum.

      Which is better code?

      On an XP project, when is it ever worth the additional effort to take
      code that passes its tests and polish it for presentation? In fact,
      isn't aiming for perfection a kind of YAGNI violation all along?
      Shouldn't the aspirations of an XP developer be 'code that works,
      that's simple, and that does no more than it needs to'. Agreed,
      sometimes the two coincide, and the code produced turns out to be
      really good--fit for mounting. But often times it's not. It seems to
      be that the XP ethic would say that merely not being the best you
      could write is no excuse for refactoring or tinkering. If it passes
      tests and contains no duplication, it gets to stay as it is, warts and
      all.


      Regards



      Dave


      --
      Thomas Consulting.
      Innovative and successful developments with Unix, Java, C, and C++.

      Now in bookstores:
      The Pragmatic Programmer. www.pragmaticprogrammer.com/ppbook/
    • Ken Auer
      ... To throw a twist into this conversation... IMO, it s unprofessional to not ship code because there is still some cruft in it. What is professional? ... it
      Message 82 of 82 , Mar 16, 2000
        > > IMO, it's unprofessional to ship crufty code...
        >
        > I feel the same way, but why does anyone feel that way? Isn't it more a
        > warrior ethic or creed that makes us want to do our best? I think
        > Xp'ers like writing great-looking code. What is "professional"? I'm not
        > sure the economic argument pans out. Even if it weren't economic to do
        > my best, I'd still do my best.

        To throw a twist into this conversation...

        IMO, it's unprofessional to not ship code because there is still some cruft
        in it.

        "What is professional?"... it is not perfectionism. (I don't remember who
        the original poster of this was, and I'm not accusing anyone in particular
        of anything, just trying to start a different slant on the conversation).

        I constantly find myself leaving code in the system that I think could be
        better. But only when I'm not sure how to make it better. E.g. I find that
        Java's typing model causes me to encapsulate casting in order to keep user's
        of a class from having to cast... (I never had to do that in Smalltalk, but
        that's a completely different thread). So, I often end up, after lots of
        functionality being added and a bunch of refactoring, finding that I have
        small classes that exist mostly to encapsulate the generic stuff underneath
        it and insert some type intelligence. The code looks almost exactly the
        same as a couple of other classes that also add similar type intelligence
        for a different type. I hate it, but it's not always obvious or possible to
        get rid of it.

        Sometimes, later, I learn a new trick that can help me clean up the cruft.
        I typically don't go and find all of the places in the system that I can
        apply the trick. The customer would be pretty bummed out if I took 2-3 days
        to do that and missed the iteration. However, I do communicate the trick
        (often through the pair-vine, but sometimes at a StandUpMeeting or on the
        whiteboard with a small group), and encourage people to apply it when their
        in code containing the particular suspect cruft.

        Eventually, the cruft works itself out and new flavors of cruft works its
        way in. The key is to never insert cruft that has a known cure, and remove
        the old cruft the next time you have to add something where the cruft lives.

        Ken

        -----------------
        Ken Auer <kauer@...>
        The Extreme Programming Software Studio(TM)
        RoleModel Software <http://www.rolemodelsoft.com> (v) 919-557-6352
        5004 Rossmore Dr. (f) 919-552-8166
        Fuquay-Varina, NC 27526 (m) 919-630-5807
        "Christianity is not a plug-in, it's an operating system"
        Mark 12:28-31
      Your message has been successfully submitted and would be delivered to recipients shortly.