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

Re: Ways XP is broken (Was:[XP] Do people prefer to fail than to admit a paradigm change?( or is XP a poisoned term? ))

Expand Messages
  • yahoogroups@jhrothjr.com
    ... From: Jim Shore To: extremeprogramming@yahoogroups.com
    Message 1 of 75 , Nov 1, 2003
    • 0 Attachment
      ----- Original Message -----
      From: "Jim Shore" <jshore.at.titanium-it.com@...>
      To: "extremeprogramming@yahoogroups.com"
      <extremeprogramming.at.yahoogroups.com@...>
      Cc: "industrialxp@yahoogroups.com"
      <industrialxp.at.yahoogroups.com@...>
      Sent: Saturday, November 01, 2003 1:52 AM
      Subject: Ways XP is broken (Was:[XP] Do people prefer to fail than to admit
      a paradigm change?( or is XP a poisoned term? ))


      > From: Ken Boucher [mailto:yahoo@...]
      > > Well, if XP is breaking in a repeatable fashion
      > > in different areas and they're all applying the
      > > same fix, then maybe we need to consider moving
      > > that fix "up" so that the next people who start
      > > an XP shop don't start with a "broken" product.
      >
      > This could be a very interesting discussion. Let's talk about ways XP
      > is broken.
      >
      > I see three ways XP is broken. Customer practices, company interface,
      > and legacy code:
      >
      > 1) XP provides a lot of support for programmers in the way of detailed
      > coding practices. It provides good support for planning. It has
      > virtually no support for the customer. I'd like to see practices that
      > help guide the XP customer in his (or her) job.
      >
      > 2) XP says nothing about ways to interface the programming project with
      > the rest of the organization. Alistair Cockburn talks about
      > "organizational antibodies" that attack XP. I've seen examples of this.
      > I'd like to see XP address making XP a part of the organization (not
      > adopting XP; how it fits in). Particularly in terms of guiding
      > companies to take advantage of XP's agility.

      That's a much more generic problem that I've brushed up
      against ever since 1973 when I found GOD. Specifically,
      Grid Organization Development. The best thing I've seen
      recently in this area is Lean thinking. The trouble is, any
      approach to restructuring an organization so that it works
      right requires a man at the top with the personality of an
      oxyacetalyne torch and the tenacity of a bear trap. It's
      getting somewhat easier since Lean Manufacturing is
      now "the right way" to do manufacturing, even though
      much of the industry hasn't figured it out yet. It's past the
      early enthusiast stage and well into the early adopter stage.

      The equivalent for software development is Lean Software
      Development. That's the title of a book by Mary and Tom
      Poppendieck. Read it. Preferably before you hit the sack
      tonight.

      I'm not sure if there's one for the "typical" organization yet.

      > 3) XP works because it creates a codebase with unique properties. Many
      > of us work with legacy code. I'd like to see XP address working with
      > legacy code. Maybe that means saying "vanilla XP won't work; use the
      > modified coding practices of LXP (legacy XP) instead."

      There's a book out (coming out?) on legacy code. I haven't gotten
      too excited about it because that's just about all I've done in a
      third of a century, so most of it's going to be old stuff.

      The thing is, there's no mystery about working with legacy code,
      unless you don't have the overall structure of making a change
      firmly embedded in your mind. To review what it is:

      1. Get the requirements. In XP, this means either talk to
      the customer (representative) or grok the already existing
      automated customer tests. Preferably both.

      2. Figure out what needs to change to install the desired
      functionality. This means read the program.

      3. Refactor the program until the desired change will
      install easily.

      4. Make the change.

      5. Refactor the program (and programmer tests)
      until it meets your team's criteria for design goodness.
      If your team doesn't seem to have one, you can't get
      much better than Kent Beck's 4 rules for simple code.

      If you're working with a greenfield project, where
      the code is always in pristine shape, most of the time
      you ignore step 3. With legacy code, you ignore step
      3 at your instant peril. You're going to have to write a
      lot of unit tests to support the refactoring, and probably
      have to decouple a lot of stuff on the way. All that means
      in practice is that you add it to your estimates going in.

      > I also think XP needs to say more about the role of testers/QA and
      > project management. (There's lots of interesting stuff happening the
      > testers arena, fortunately.)

      I thought most of that was clear. QA's role is on the front end,
      clarify requriement, and in the middle, making sure that the process
      itself produces quality results. It's not on the back end.

      > I'd also like more about what happens during deployment.

      Whatever you need to happen. Seriously - there are too many
      deployment scenarios for a generic process to address them all.

      XP's point is that what's on your server ***IS*** deployable.
      I can't emphasize that too much. Deployable means that the
      development team doesn't need to do *anything* for the
      program to roll out to the field. It's already been done, the
      ramp is greased, the ball is ready to drop.

      > Incidently, I think Josh Kerievsky's Industrial XP has got a huge amount
      > of promise for addressing points 1) and 2) above.
      >
      > Jim

      John Roth
    • Roy Miller
      ... Programming ... 12 ... ROI ... the ... to ... Consider this confirmation, at least from me. Please do use all the practices when you can, but John s right.
      Message 75 of 75 , Nov 28, 2003
      • 0 Attachment
        > >>Ken Auer and Roy Miller propose in their book ("Extreme
        Programming
        > >>Applied", page 71), that although it is better to start with all
        12
        > >>above mentioned practices, it is also feasable to start with only
        > >>the following 6 practices. Ken and Roy call them essential
        > >>practices.
        > >
        > >>Planning Game
        > >>Small Releases
        > >>Testing
        > >>Pair Programming
        > >>Refactoring
        > >>Continuous Integration
        >
        > I interpreted this differently. I pictured them saying that, in an
        > environment that seems hostile to XP, these are the practices worth
        > fighting for just to get your foot in the door. The rest have less
        ROI
        > when you include the effort you spend trying to convince people in
        the
        > "expense" column.
        >
        > I don't think they mean that the remaining practices are candidates
        to
        > discard on an XP project with the appropriate buy-in.
        >
        > Of course, Ken or Roy could just confirm or deny that themselves.

        Consider this confirmation, at least from me. Please do use all the
        practices when you can, but John's right. You sometimes need to pick
        your battles. Win the first set of battles, then move on to the next
        set. I think you'll like the results.

        Roy
      Your message has been successfully submitted and would be delivered to recipients shortly.