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

[extremeprogramming] Re: Elves in the Night [Stupid XP Question Number 6614]

Expand Messages
  • Robert C. Martin
    Dave Thomas wrote in message news:m24scvaz2c.fsf@zip.local.thomases.com... ... manifest. ... opportunities for ... it. ... If your customer
    Message 1 of 38 , Jan 3, 2000
      Dave Thomas <Dave@...> wrote in message
      news:m24scvaz2c.fsf@......
      > "Robert C. Martin" <rmartin@...> writes:
      >
      > > > So, my problem is that XP as espoused doesn't allow me to use my
      > > > experience to reduce risk.
      > >
      > > Yes it does. It just asks you to wait until the risk is actually
      manifest.
      > > As you work in an XP project, you will find all kinds of
      opportunities
      for
      > > adding infrastructure. But you wait, rather than immediately adding
      it.
      > > You wait until its clear that the infrastructure is really needed.
      >
      > So I'm only allowed to add a nightly job to back up the repository
      > only after we've had a disk crash and lost all the source?

      If your customer has not made nightly backups a priority, then they must
      be
      willing to lose all the source. Clearly you want to make sure the
      customer
      knows what they are risking. But if they prioritize other features
      above
      the nightly backup, you have no business building the nightly backup
      first.
      It's their nickel, after all.

      > That's not as facetious a question as it sounds at first.

      Nor did I interpret it facetiously. Indeed, it is right to the point.
      There are things that make a tremendous amount of engineering sense that
      may
      make no business sense. We, as engineers, have a tough time
      understanding
      this. Still, we exist to serve the business. When the business
      countermands our engineering instincts, the business wins.

      This doesn't mean we sacrifice on quality. Those features that business
      tells us to create, we create with the best of our skills. But we do
      not
      add features that business has not made a priority.

      > My experience tells me it's good to take backups. I set them up on all
      > new projects. I don't wait until I bump into the real-world need
      > before doing it.

      And since you, as the software engineer, are the customer of the
      development
      environment, you have that right. But you don't have that right with
      customer features. If the customer does not want you to back up the
      employee database every night, even after you have warned him of the
      risk,
      then you don't back it up.

      > Why is this different to saying 'my experience tells me we'll need an
      > logging and tracing facility for everyone to use. Let's code one up
      > front"?

      If that statement is true, then at least two people in the first
      iteration
      will need it. That need will be identified early on, either before any
      code
      is written, or before too much code is written.

      It works like this. Bill and Bob pair up to work on feature X. They
      realize that they will have to emit messages and write them to a private
      log
      file. A few hours later, Bill pairs with Jim. Bill sees that Jim has
      also
      been writing to a log file. Bill, Jim, and Bob realize that there is
      duplication in their efforts. They quickly poll the team to see if
      others
      have faced this need. If so, the team quickly convenes to design a
      logging
      facility. Everybody changes their code (only a few hours worth have
      been
      written) and they go on from there.

      This scenario repeats often because pairs change frequently. By the end
      of
      the first few days of an XP project, everybody has seen all the code and
      is
      familiar with the basic design of the system. They have also found
      commonalities and refactored them into abstractions and infrastructure.

      Is there rework? Certainly. But it is minimal. And the benefit is
      that
      the abstractions, once created, are based upon something very real.
      Many is
      the time I've had to rework large chunks of code because others had
      written
      to my bad abstractions that were based upon what I *thought* would be
      needed.


      --

      Robert C. Martin | OO Mentoring | Training Courses:
      Object Mentor Inc. | rmartin@... | OOD, Patterns, C++,
      Java,
      PO Box 85 | Tel: (800) 338-6716 | Extreme Programming.
      Grayslake IL 60030 | Fax: (847) 548-6853 |
      http://www.objectmentor.com

      "One of the great commandments of science is:
      'Mistrust arguments from authority.'" -- Carl Sagan
    • Robert C. Martin
      Tom Kreitzberg wrote in message news:387364E4.C0A3E6CC@jhuapl.edu... ... There is no fundamental difference between pre XP Object
      Message 38 of 38 , Jan 5, 2000
        Tom Kreitzberg <Tom.Kreitzberg@...> wrote in message
        news:387364E4.C0A3E6CC@......

        > But I think "flexibility" means different things to XP and,
        > shall we say, pre-XP OMA. In XP, doesn't it primarily mean
        > once and only once? In pre-XP OMA, doesn't it primarily mean
        > OCP and low coupling? When I wrote that XP "is structured so
        > that inflexible designs are cheap to change," I meant inflexible
        > in this second sense.

        There is no fundamental difference between pre XP Object Mentor, and
        post XP
        Object Mentor except that we have identified XP as the process we like
        to
        use. Even this is not a big shift for us, since XP is very similar in
        spirit and practice to the unnamed process we have used for years.
        There
        are differences, certainly -- specifically in the areas of pair
        programming
        and test first programming; but these are differences in intensity, not
        in
        philosophy. As for the rules governing simplity, the planning game,
        quick
        iterations, etc, we were very closely aligned.

        Flexibility means the same to me now as it did five years ago. The
        ability
        to add or change significant amounts of functionality while changing a
        minimum of exsiting code -- i.e. the OCP. OnceAndOnlyOnce leads to this
        goal just as the OO design principles do. It is my goal over the next
        several months to integrate the principles and XP.
      Your message has been successfully submitted and would be delivered to recipients shortly.