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

Beginning with Legacy ...

Expand Messages
  • Ron Jeffries
    So on the topics of beginning XP, what about teams who have no really green-field area to work in? It seems to me that using XP in a legacy situation, with a
    Message 1 of 54 , Jan 2, 2004
    • 0 Attachment
      So on the topics of beginning XP, what about teams who have no really
      green-field area to work in? It seems to me that using XP in a legacy
      situation, with a team inexperienced in XP, offers some very difficult
      challenges:

      - the code base isn't all that clean;
      - the code base may not even be well understood;
      - we don't have a shell of decent tests to support refactoring;
      - we can't predict very well how long things will take
      - ... and so on ...

      Meanwhile, as a beginning team, we have not as yet built up strong XP
      skills:

      - we aren't very good at eliciting simple code with short simple tests
      - we aren't skilled at refactoring
      - we may not know how to pair program
      -- and pair debugging isn't pair programming
      - we may not be organized to work together
      - we may be specialized
      - our goals may be very aggressive and our performance falling short

      So ... tell me of your experience trying XP on legacy systems, with people
      who are new to XP?

      Ron Jeffries
      www.XProgramming.com
      There is no award for "being XP". There is an award for doing the right
      combination of practices: success.
    • PaulOldfield1@compuserve.com
      (responding to Tim H) ... I ve been in a similar position - 15 years ago, average compile time 1 hour, worst case compile time 9 hours, sparse test suite
      Message 54 of 54 , Jan 15, 2004
      • 0 Attachment
        (responding to Tim H)

        > I've been in a similar position with no tests, and
        > about 1 million lines of highly fragile untested code.
        > Fear, nay, terror prevented me from refactoring it.
        > Testing it in its entirity was very costly, not testing
        > it meant that new bugs would slip through.

        I've been in a similar position - 15 years ago, average
        compile time 1 hour, worst case compile time 9
        hours, sparse test suite (thorough acceptance tests
        but nothing else). Refactoring was obligatory, we
        had a 'monolithic' program that needed to be
        split into client and server. Apart from that, no new
        requirements at all.

        > Were you lucky? Or is there magic at work here??

        I was *very* careful, though occasionally I needed to
        roll back a whole day's work. The rest was magic.
        Refactoring was something I'd invented for myself,
        though I'd read the original SigPlan Notices article
        by this time. I wrote up the experience in Ada User.

        Paul Oldfield
        www.aptprocess.com
      Your message has been successfully submitted and would be delivered to recipients shortly.