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

An XP Experiment (long)

Expand Messages
  • Paul Michali
    Hi, In my quest to learn more about XP, I ve decided to take a program that I had wrote before and redo it from scratch using XP practices. I m posting about
    Message 1 of 4 , Nov 29, 2000
    • 0 Attachment
      Hi,

      In my quest to learn more about XP, I've decided to take a program
      that I had wrote before and redo it from scratch using XP practices.

      I'm posting about it here, in the hopes to stimulate some discussion
      and learn more about the XP practices from others.


      For this exercise, my primary goals are to try test first programming,
      work with stories and tasks, and get some more exposure to working
      with Java. Having already implemented the application, I'd like to
      see how test first programming influences the design.

      So, if you're interested, read on (it's long)...

      -----------------------------------------------------------------

      The application: PathFinder

      Background

      After the company I work for was acquired, we were moved to another
      location. This location has increased my commute time (40 miles now)
      and that coupled with the fact that there are multiple routes I
      could take to work and that each one can become severely congested,
      I decided to make a program to assist in my commute. I know of a
      web site that posts traffic conditions on various roads. I can view
      the web pages to see how the traffic is on each route. If I do that
      several times before I leave, I get a reasonable (time delayed, of
      course) picture of the conditions so that I can decide which way to
      go. I decided to use the feature of my alphanumeric pager, where I
      can send an short e-mail message to the pager to notify of the
      conditions. I plan on sending those notices for some time after I've
      left, so that I can change my route, if things go bad just after
      I've started traveling (before I get to a point where I'm committed
      to one path). I don't want to get a ton of pages, so I want to be
      notified only if conditions get bad. Once bad, I'd want to know, if
      they get better. I will always travel on one route, unless I get a
      notification of bad conditions on that route.


      Metaphor for PathFinder

      The army unit sends out two scouts, one on a direct path
      to the target destination and one on an alternate path.
      The scouts each report back whether or not there were
      enemy troops along the path and how many. Scouts are sent
      back out at regular intervals. When it time to move the
      troops, the commander decides which route is best based on
      the scouting reports and will go toward the target destination
      on the chosen route. The scouts are still sent out at regular
      intervals, until the army reaches a point of no return,
      of which the army is committed to one of the routes.

      The army leaves every morning for a target destination and
      then leaves every evening to return to their home base. They
      go to the same destination, each time they travel.


      Story 1 [monitoring]

      Monitor a primary and secondary route every "x" (programmable)
      minutes. After "y" (programmable) minutes, which is a multiple
      of "x", evaluate the routes. Continue the monitoring and
      evaluating every "x" minutes, until a total of "z" (programmable)
      minutes, which is also a multiple of "x", has elapsed. Perform
      this process two times a day.


      Story 2 [evaluating/notifying]

      If the primary route status changes, then notify the user(s) of
      both the primary and secondary route conditions. The status info
      is available from web pages at a remote site. The notification is
      via e-mail (typically this will be an alpha pager address). May
      notify one or more "users" (addresses).


      Story 3 [configuring]

      Obtain the following information programmatically; web page for
      primary and secondary roads, string to parse to obtain status
      information for route section of interest for each road,
      monitoring interval (x), evaluation delay interval (y), and
      total monitoring time (z). Two sets of information can be
      defined, one for the destination and one for the origin.


      Story 1 Task A [checking] {0.5 hours ideal}

      Wait "x" minutes and then check each route's status. After "y"
      minutes, evaluate the route. Continue checking and evaluating
      every "x" minutes, until a total of "z" minutes has elapsed.
      This program will be invoked twice a day (may have different
      values for x, y, and z).


      Story 2 Task A [evaluating] {1 hour ideal}

      Check the status of each route by reading a specific web page
      that contains several route sections for a road. Parse the
      page to find the status information for the route section
      desired. Obtain the status indication for a route, by looking
      at the alternate text for the route status image. Parse the
      "report time" from the web page, Parse the status message for
      the route section. This is after the route status image HTML
      element and extends until the next HTML tag that is not a <b> .
      Save this info as current conditions. {would reference text
      files that have captured web page sources}


      Story 2 Task B [notifying] {0.5 hours ideal}

      If the primary route status has changed from OK to another status,
      then notify the user(s) of both routes. Subsequently, if either
      route changes status (good to bad or vice versa) or the status
      message changes, then notify the user(s) of both routes. The
      notification is via e-mail and includes the "report time" that
      the condition change was "announced" by the web site, the current
      route status, and any associated status message for the route.
      Provide the same information for both routes (so user can decide
      if the alternate route is any better).


      Story 3 Task A [configuring] { 0.5 hours ideal}

      Read a text file that contains the web pages for the primary and
      secondary roads, the text that is used to identify the route
      section for each road, the monitoring interval, the notification
      start delay, the total monitoring interval, and a list of
      notification e-mails. Two files will be used, one for the morning
      and one for the evening. The "AT" service will be used to run
      the PathFinder application and specify the configuration files to
      use.


      QUESTIONS/COMMENTS:

      Should my "background" have been the story or stories? In other words,
      are my stories too implementation dependent?

      How is the granularity of each story? Should I combine stories?

      Do the tasks seem detailed enough? I have enough info that *I* could
      implement them, but I'm not sure if they should be more specific for
      others to understand.

      At first glance, it looks like most of the tasks could be implemented
      independently. I'm concerned about Story 2 Task A, as it "seems" like
      I'd need to have Story 3 Task A done first. Should I try to implement
      Story 2 Task A first to see if I can do it w/o dependencies?

      I didn't estimate the stories, but I gave a stab at the tasks (shown
      above). I figure on using a factor of three to get velocities. Adding
      them all up, I get 7.5 hours.

      The next step will be to start writing tests for each of these tasks.
      I'll track the time I spend to see how the estimates come out.

      Any other comments/suggestions?


      PCM (Paul Michali)

      Voice Gateway Solutions Business Unit (VGSBU)
      Cisco Systems, Inc.
      250 Apollo Drive
      Chelmsford, MA 01824

      Phone : (800) 572-6771 x 45817 (978) 244-5817 [direct]
      Paging: (800) 365-4578 [voice] pcm@... [email page]
    • Ron Jeffries
      This is a cool writeup. Keep it going. I ll note some things here. They are just suggestions, refinements, things that come to mind. As always I wrote a lot.
      Message 2 of 4 , Nov 29, 2000
      • 0 Attachment
        This is a cool writeup. Keep it going. I'll note some things here. They are
        just suggestions, refinements, things that come to mind. As always I wrote
        a lot. Take it as support, not criticism. I'd be really brief if I didn't
        think you were doing great!

        In a "real" project, there might well be MANY fewer words in the background
        and metaphor, since you'd be right there with the customer. For us it's
        great, and it wouldn't surprise me if a given customer wrote that much just
        to get their own thoughts in order. But imagine how hard it was to write,
        and how easy it would have been to explain the thing over coffee. Now
        imagine how much we have LOST from our reading because we weren't there for
        the coffee explanation.

        The written stories are VERY detailed compared to how detailed they need to
        be if on cards and with on-site customer. The third one might just say:

        "Be able to configure all the variables, like where to get the info, the
        pager numbers, and time intervals."

        It might even say "Make everything configurable" and then be broken down into

        "Make time intervals configurable"
        "Make web site and string parsing configurable" or even "Use web site Y
        instead of X"

        Here's why this is important: you could spend a lot of time getting it
        generalized, with little benefit. It's the first version (the one that gets
        you to work) that has the bulk of the value. This is true of most real
        products also: get value to SOMEONE early on.

        One last thing: the stories are written so that you don't get much benefit
        until at least story 1 and 2, and maybe part of 3, are done. See if you can
        think of useful stories like these:

        "Monitor Web site X every 5 minutes and beep pager with the text"

        This has only one web site, no evaluation, a fixed interval. But in fact,
        though it would drive you nuts beeping, it would be useful. Then your next
        story is

        "Fix that infernal beeping. Only beep for bad messages, i.e. those that say
        'accident' and not 'cleared'", or something like that.

        Then you go to an alternate route only to find that it sucks even worse.
        Add the story "beep for this other specific route also".

        And so on. You're making the program useful in the very first half hour
        (more like a week in a real application), and then making it more and more
        useful as you go along.

        Don't let the length of t his reply or the changes I'm suggesting get you

        down: you're doing great! These are just things that take teams months to
        really begin to learn. Keep it going!

        Ron Jeffries
        www.XProgramming.com
        www.objectmentor.com
      • Kevin Smith
        ... (snip...other snip s won t be explicitly called out) ... This was interesting and helpful, especially to people like us who are not directly in the
        Message 3 of 4 , Nov 29, 2000
        • 0 Attachment
          > In my quest to learn more about XP, I've decided to take a program
          > that I had wrote before and redo it from scratch using XP practices.
          >
          > I'm posting about it here, in the hopes to stimulate some discussion
          > and learn more about the XP practices from others.
          (snip...other snip's won't be explicitly called out)

          > Background

          This was interesting and helpful, especially to people like
          us who are not directly in the project. Not essential.

          > Metaphor for PathFinder

          Well done. As various surveys have indicated, metaphors are
          not widely used. Yours makes sense.

          > Story 1 [monitoring]

          As Ron mentioned, the stories are pretty verbose, and don't
          seem to point to business value as quickly as they could.
          I'll take a stab (along the same lines as Ron). Perhaps it
          will help.

          Story 1:
          Scrape relevant stuff off website X (hard-coded) every "n"
          (hard-coded) minutes and email it to the pager (a hard-coded
          email address).

          Story 2:
          Scrape and page between two (hard-coded) start end times
          each day [weekday?].

          Story 3:
          Only send pages if/when the status has changed since the
          previous page.

          Story 4:
          Scrape a second route at the same time. Still only send if
          the primary route status has changed.

          Story 5:
          Additional bells and whistles, such as reading email
          address(es) and/or time and interval settings from a
          configuration file.

          Hopefully I got all your requirements in there. Personally,
          I would want to be notified if either route status had
          changed, because if the primary route changed to "bad" and
          stayed there, but the secondary route then changed from
          "good" to "horrible", I'd want to know it. Of course, you're
          the customer.

          > QUESTIONS/COMMENTS:
          >
          > How is the granularity of each story? Should I combine
          stories?

          In a commercial project with 2 or more full-time developers,
          you would want meatier stories. On my own XP-for-one hobby
          projects, I like to use small stories like these. It lets me
          pretend that I'm making a lot of progress even if I only put
          in a couple hours a night.

          >
          > Do the tasks seem detailed enough? I have enough info that *I* could
          > implement them, but I'm not sure if they should be more specific for
          > others to understand.

          They seemed to have more than enough for me to implement. A
          story is a promise to have a conversation with the customer
          about what is really needed. (But don't let anyone see you
          ask yourself what you really want! Our culture frowns on
          such things.)

          The tasks should be more detailed than stories, as yours
          were.

          >
          > At first glance, it looks like most of the tasks could be implemented
          > independently. I'm concerned about Story 2 Task A, as it "seems" like
          > I'd need to have Story 3 Task A done first. Should I try to implement
          > Story 2 Task A first to see if I can do it w/o
          dependencies?

          I think if you focus more on little slices of value, you'll
          find fewer dependencies. Keep in mind that YOU are the
          customer, so if YOU can live with hard-coded values, there's
          no need to spend time making them configurable. YAGNI.

          > The next step will be to start writing tests for each of these tasks.
          > I'll track the time I spend to see how the estimates come out.

          I assume you mean that the next step will be to attack the
          first task, repeatedly cycling between writing a little
          test, writing a little code, and doing a little refactoring.
          You wouldn't write all the unit tests for a task at once,
          let alone tests for multiple tasks at once.

          > Any other comments/suggestions?

          Way cool. If I had a bad commute, I'd steal your idea.

          I am considering starting my own ruby project at home, doing
          XP-for-one. Assuming I move forward with it, I'll probably
          toss my story list up here for a critique like you did.
          Thanks for sharing.

          Kevin
        • Duncan McGregor
          What a cool thread this is. Thanks for sharing your experiences Paul. Can I ask what you based your estimates on? It seems to me like 2.5 ideal hours was a
          Message 4 of 4 , Dec 1, 2000
          • 0 Attachment
            What a cool thread this is. Thanks for sharing your experiences Paul.

            Can I ask what you based your estimates on? It seems to me like 2.5 ideal
            hours was a little, well, optimistic. Whereas a velocity of 1/3 when you are
            working alone and at home seems low.

            I would have estimated the lot at 15 hours. When I'm working on my own stuff
            the meetings and so on that are normally accounted for in velocity don't
            apply - instead I just estimate the end time bases on the number of hours I
            expect to be able to devote to the problem (say 2 hours tonight, 4 over the
            weekend, one more on Monday). I'm on my own, so there's no pairing factor to
            include either. The result is that, bar statistically-large unforeseen
            technical hitches, I usually get away with a velocity of one.

            I guess if I was working out how many elapsed weeks it would take to do a 5
            ideal-man-day project I would fall back on a velocity of (10 hours a week =
            1.5 days a week = 0.2). Hey, that's pretty close to yours - was that your
            reasoning?

            Waiting to see how it turn's out...

            Duncan Mc^Gregor
            "The name rings a bell"




            *************************************************************************
            The information contained in this message or any of its
            attachments may be privileged and confidential and intended
            for the exclusive use of the addressee. If you are not the
            addressee any disclosure, reproduction, distribution or other
            dissemination or use of this communication is strictly prohibited
            **************************************************************************
          Your message has been successfully submitted and would be delivered to recipients shortly.