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

FW: The Cost of Change Curve

Expand Messages
  • Gary Brown
    Below is my reply to Luke s offline note. WARNING - it includes my admisson of guilt to being a consultant trying to sell XP!
    Message 1 of 2 , Apr 2, 2004
    • 0 Attachment
      Below is my reply to Luke's offline note. WARNING - it includes my
      admisson of guilt to being a consultant trying to sell XP!

      > -----Original Message-----
      > From: Gary Brown [mailto:glbrown@...]
      > Sent: Thursday, April 01, 2004 8:35 AM
      > To: 'lukehohmann'
      > Subject: RE: The Cost of Change Curve
      >
      >
      > Thanks for the note, Luke!
      >
      > Has the cost of change curve flattened? A definite maybe.
      > It depends on the team. If we have the discipline to always
      > TDD every line of production code and refactor mercilessly,
      > then I believe the answer is that the cost of change curve is
      > much flatter than if we don't do those things. Can the cost
      > of change curve ever be perfectly flat? I don't think so,
      > because we don't know what we don't know, but we do have to
      > move forward and deliver the best system that our skills
      > allow right now. I think that the relative bumpiness depends
      > on the team, more than any external force.
      >
      > The reason that I said you hit the wall is in the context of
      > "proving your architecture". Assume that a team does have
      > the discipline to TDD every line of production code and
      > refactor mercilessly. This means that their codebase is able
      > to move is whatever direction is needed, for much lower cost,
      > than a team who doesn't do those things. XP is about
      > delivering customer value, not about delivering architecture.
      > The focus on architecture is a big part of what spawned the
      > waterfall process and its slightly improved decendent, RUP.
      >
      > My real complaint though, is here we have prominent member of
      > the agile software development community, providing
      > ammunition to the opposition. I spend part of every day
      > working to convince people that they ought to be doing XP for
      > various reasons, one of which is the potential to flatten the
      > cost of change curve. I am trying to build a consulting
      > practice focused on agile development. When I talk to senior
      > managers, they know that they have a problem. They want a
      > better process. They want to deliver value to their
      > customers in less time with fewer defects. After I talk to
      > those senior managers, they often do their own research, or
      > talk to their senior developers about XP. In our next
      > meeting, they come prepared with all of the reasons why they
      > can't or won't adopt XP. Most of their rationale is plain
      > old FUD, and resistance to change. Now, I'm going to have to
      > form a strategy to deal with this whole bumpiness thing. 8^)
      >
      > If you are familiar with Geoffrey Moore's books, "Crossing
      > the Chasm" and "Inside the Tornado", he talks about the
      > Technology Adoption Life Cycle, which is about marketing new
      > technology. He divides the audience of potential technology
      > customers into EarlyAdopters, Pragmatists, Conservatives, and
      > a couple of other less important groups. I'm going to guess
      > that you are an EarlyAdopter, I know that I am. In order for
      > XP to move into the mainstream, it has to "cross the chasm"
      > between EarlyAdopters and Pragmatists. I think that the
      > EarlyAdopter market for XP is fairly well saturated. It is
      > time for XP to move into the mainstream or die a slow
      > miserable death. I think that your bumpiness concept is
      > worth talking about in terms of what will happen to teams
      > that try XP without the requisite discipline. To me, it is
      > unhelpful to talk about bumpiness in terms of architecture,
      > because of the power of that word to breed FUD.
      >
      > Some architecture decisions are obvious. The up front
      > decision process takes a few seconds. We need to convert the
      > order entry system from green screen to web. The data is
      > currently in an IMS data store. We already own Oracle and
      > have experienced developers. Let's use Oracle. We would
      > like to use Java, for portability reasons, but we have no
      > expertise. We know VB and we have developed some small
      > ASP.Net applications. Let's use ASP.Net and VB. If that's
      > BDUF, then I guess I'm guilty! 8^)
      >
      > I am also working on a project to convert an existing system
      > that had its technology pulled out from under it. And, we
      > are installing XP at the same time. It is difficult and it
      > will be expensive, but we believe that XP will allow us to
      > get this done in less time and at a lower cost, if we are disciplined.
      >
      > Here's to a less bumpy path!
      >
      > GB.
      >
      > > -----Original Message-----
      > > From: lukehohmann [mailto:luke@...]
      > > Sent: Thursday, April 01, 2004 12:07 AM
      > > To: Gary Brown
      > > Subject: Re: The Cost of Change Curve
      > >
      > >
      > > Gary -
      > > Brad Appleton invited me to read and possibly contribute to this
      > > exchange, since my name is referenced. Since I need a break
      > from some
      > > work I'm doing, I'll join the conversation.
      > >
      > > First, I encourage you to actually answer Shane's question: In your
      > > experience is the cost of change curve as smooth prominent
      > members of
      > > the XP community claim?
      > >
      > > Second, I'm having a hard time understanding how you think
      > I've hit a
      > > wall or how you claim I'm practicing RUP/POWFOF thinking. If you've
      > > taken the time to read my ample writings on the topic, I have long
      > > advocated an organic, change-friendly approach to architecture and
      > > design decisions. I'm not afraid of failure -- I expect that there
      > > will be problems.
      > >
      > > I stand behind all of my writings, and certainly my comments in my
      > > interview with Bill. In the first release of a software product,
      > > you're proving out your architecture. You've made your
      > design choices
      > > as best you can, based on what you know, but it isn't until the
      > > system is in use that you'll know how you did. There is always the
      > > chance that you'll hit some major architectural flaw in a
      > system, no
      > > matter what approach you're using. I expect it, and my experience
      > > says that the cost of change curve is therefore bumpy.
      > >
      > > I also tend to work on projects that are already in production,
      > > sometimes for many, many years. Here is another example of
      > a "bumpy"
      > > change curve. One client is currently porting a major embedded
      > > application from one device to another, because the current device
      > > manufacturer has elected to stop producing the device. There is no
      > > changing the decision -- some needed chips are no longer
      > made. Let's
      > > just assume that the original team creating this software was
      > > a "perfect XP team". Despite all of their truly great
      > efforts, their
      > > cost of change curve is sky-high right now, because they are being
      > > forced to rewrite everything from scratch (the new device
      > is based on
      > > a new OS, with a new file system, new physical form factor for the
      > > UI, different threading model, etc.). This kind of thing happens.
      > > Platforms change. Things shift. APIs that you relied on get
      > > deprecated. All of these contribute to a bumpy cost of
      > change curve.
      > >
      > > Frankly, I think the way that your portraying the cost of change
      > > curve is based much more on waterfall thinking than my own. You
      > > write: "If your application needs a database, then include it". Uh,
      > > that means that you knew about that need up front. In my
      > experience,
      > > not every "need" is known up front.
      > >
      > > Regards,
      > >
      > > Luke Hohmann
      > > www.lukehohmann.com
      > >
      > > --- In extremeprogramming@yahoogroups.com, "Gary Brown"
      > > <glbrown@i...> wrote:
      > > > Shane,
      > > >
      > > > With massive appologies in advance to Luke Hohmann. Luke hits the
      > > wall
      > > > in paragraph 2 when he says "In the first release, you're proving
      > > out
      > > > your architecture". This is at best good RUP thinking, and
      > > at worst
      > > > POWFOF (Plain Old Waterfall Fear Of Failure) thinking.
      > It has been
      > > said
      > > > here many times, "simple design is not stupid design". If your
      > > > application needs a database, then include it.
      > > >
      > > > Gary Brown
      > > >
      > > >
      > > > > -----Original Message-----
      > > > > From: Shane Mingins [mailto:shanemingins@y...]
      > > > > Sent: Wednesday, March 31, 2004 8:28 PM
      > > > > To: extremeprogramming@yahoogroups.com
      > > > > Subject: [XP] The Cost of Change Curve
      > > > >
      > > > >
      > > > > Hi
      > > > >
      > > > > I was reading a couple or articles the other day. The first was
      > > an
      > > > > older one by Martin Fowler, Is Design Dead
      > > > >
      > > > > http://martinfowler.com/articles/designDead.html
      > > > >
      > > > > and then the second was an interview with Luke Hohmann
      > > > > http://www.artima.com/intv/entropy2.html
      > > > >
      > > > > Martin referred to himself as being "known for being a cowardly
      > > XPer"
      > > > > and gave an example: "So my advice is to begin by assessing what
      > > the
      > > > > likely architecture is. If you see a large amount of data with
      > > > > multiple users, go ahead and use a database from day 1"
      > but pay
      > > > > homage to the gods of YAGNI with "when in doubt err on the side
      > > of
      > > > > simplicity".
      > > > >
      > > > > So I can only conclude that at the time of writing Martin was
      > > > > possibly hestitant at the ability of XP to flatten the cost of
      > > change
      > > > > curve when it came to certain architectual changes. Does that
      > > sound
      > > > > a fair conclusion?
      > > > >
      > > > > And then I read Luke's interview where he suggests that
      > the curve
      > > > > does not flatten as XP assumes but is more bumpy. He says "I
      > > applaud
      > > > > the concept of the flattening cost of change curve,
      > because it's
      > > > > right. You should be able to achieve that flattening after the
      > > first
      > > > > release or two. It's just not true for a mature product
      > over its
      > > > > entire lifecycle."
      > > > >
      > > > > Anyhow this just got me to wondering about the cost of change
      > > curve
      > > > > and the assumption that XP will flatten the change curve.
      > > > >
      > > > > Martin says "The fundamental assumption underlying XP is that it
      > > is
      > > > > possible to flatten the change curve enough to make
      > evolutionary
      > > > > design work. This flattening is both enabled by XP and exploited
      > > by
      > > > > XP. This is part of the coupling of the XP practices:
      > > specifically
      > > > > you can't do those parts of XP that exploit the flattened curve
      > > > > without doing those things that enable the flattening. "
      > > > >
      > > > > So what are the experiences of people using XP
      > practices showing
      > > > > them?
      > > > > Are you finding that the cost of change curve is
      > flattening? Or
      > > is
      > > > > it bumpy like Luke has experienced?
      > > > >
      > > > > Cheers
      > > > > Shane
      > > > >
      > > > > "Have no fear" - The Cat In The Hat (Dr Seuss)
      > > > >
      > > > >
      > > > >
      > > > >
      > > > >
      > > > >
      > > > >
      > > > > To Post a message, send it to: extremeprogramming@e...
      > > > >
      > > > > To Unsubscribe, send a blank message to:
      > > > > extremeprogramming-unsubscribe@e...
      > > > >
      > > > > ad-free courtesy of objectmentor.com
      > > > > Yahoo! Groups Links
      > > > >
      > > > >
      > > > >
      > > > >
      > > > >
      > >
      >
    • Brad Appleton
      ... I think maybe this is just different views of what architecture means above. Above, you are talking about the code being changeable. Earlier in this
      Message 2 of 2 , Apr 2, 2004
      • 0 Attachment
        On Fri, Apr 02, 2004 at 06:21:29AM -0600, Gary Brown wrote:
        > The reason that I said you hit the wall is in the context of
        > "proving your architecture". Assume that a team does have
        > the discipline to TDD every line of production code and
        > refactor mercilessly. This means that their codebase is able
        > to move is whatever direction is needed, for much lower cost,
        > than a team who doesn't do those things. XP is about
        > delivering customer value, not about delivering architecture.
        > The focus on architecture is a big part of what spawned the
        > waterfall process and its slightly improved decendent, RUP.

        I think maybe this is just different views of what
        "architecture" means above.

        Above, you are talking about the code being changeable. Earlier
        in this thread we also talked about the two factors of the
        expectations gap, which is reduced by using shorter feedback
        cycles, versus the maintainability (well factored-ness) of the
        code. I think Luke is referring to the size or amount of the
        "gap" in knowledge that needs to be "bridged" in between the
        time you started and the time the product first starts getting
        used "for real" in production.

        I agree that the bigger that gap is, the more effort it will
        be to change the code (even if the code is easy to change -
        I think its still true). And I think Luke is saying in this
        case that one is trying to "prove" the initial "vision" for
        the product/architecture, and will get a LOT of feedback
        as to exactly where it falls short. And that this "gap"
        tends to be the biggest for those capabilities that are
        being either seen or used by users for the very first time.

        I think every time one adds such a capability, this causes the
        kind of "bump" Luke describes. And the critical cycle-time
        for this isn't necessarily the time between iterations, but
        the time between deployments/upgrades. If your customers
        simply will not upgrade/deploy every iterations or so, then
        that makes the "expectation gap" take longer to close, and
        whenever you are adding a significant new capability to the
        product/architecture, this makes for bigger "bumps".

        --
        Brad Appleton <brad@...> www.bradapp.net
        Software CM Patterns (www.scmpatterns.com)
        Effective Teamwork, Practical Integration
        "And miles to go before I sleep." -- Robert Frost
      Your message has been successfully submitted and would be delivered to recipients shortly.