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

Re: [XP] Up-front vs evolutionary design -- was XP pros & cons

Expand Messages
  • William Pietri
    ... Got it. Just to make myself more clear, I think I was mainly looking for the specifics. I agree that doing more speculative work was one way that you folks
    Message 1 of 107 , May 1, 2005
    • 0 Attachment
      On Sun, 2005-05-01 at 14:46 -0400, Chris Wheeler wrote:
      > >
      > > Could you say more about this particular situation?
      >
      > I'll hop in here, if Friedrich doesn't mind. We work together, and so have
      > both experienced this. I won't get into details of the domain or specifics,
      > I don't have the energy or time now...

      Got it. Just to make myself more clear, I think I was mainly looking for
      the specifics. I agree that doing more speculative work was one way that
      you folks could have solved the problems that you noticed. I'm just
      wondering whether you could have solve them for equivalent costs with
      the existing XP tools. And the answer to that really may lie in the
      details, so I'll understand if we never get clarity on this one.

      > The problem here is that one has to balance speculation with what is really
      > known. In this case, it wasn't speculation to say that we would need this
      > particular feature. It was 100% known it would be necessary. Yet, customers
      > wanted to defer building the whole thing in favour of getting other features
      > done.

      Well, nothing is ever 100% known or 100% certain. Can we compromise on
      "it seemed very likely to us"?

      Also, it sounds like you feel that the early features plus the later
      feature would have been cheaper to build together. Care to take a guess
      at what the relative numbers were? And at the time of choosing, did you
      make the customers aware of this? E.g., did you say, "Well, you can have
      these features together now for 10 points, or you can pay 8 points now
      and 10 more later?"

      > But, the customer wanted to move ahead, so we did, and today, the cost is
      > much higher.

      Is there perhaps a path equivalently cheap that would have avoided the
      large increase in cost?

      For example, I'm in the habit of leaving persistence in a project until
      the first release, and sometimes long after that. If I do that naively,
      I might leave little loose ends all over that will be a lot of work to
      pull together when I finally add persistence. However, because I know
      persistence is coming, it makes me more aware of certain kinds of
      expressive duplication, which I then refactor away. Then adding
      persistence is still work, but it's relatively easy.


      > I am all for incremental delivery of business value. But the customer is not
      > always king. Sometimes there are technical reasons to do things now as
      > opposed to waiting for the exact business condition to set in.

      Well, I think all business activity should be justifiable in business
      value terms. But I agree that it's most efficient to treat some choices
      as purely technical ones because the business value difference isn't
      large enough to be worth educating the customer so that they can make
      the appropriate decision.

      However it's generally my experience (and XP theory as well) that the
      various technical mumbo-jumbo is small enough and consistent enough in
      business impact to get rolled into velocity.

      It sounds like you're saying that your team had an incident where y'all
      couldn't find a way to make a technical issue fit that profile, and that
      with hindsight the best solution you can come up with would have been
      taking a velocity hit early on to make future cards easier.

      That sounds reasonable to me, and I've certainly had experiences like
      that. But I've also had enough experiences where later on I've found
      other, more XPish ways to do that as well. So I'm hesitant to make the
      leap and say that XP sometimes gets this wrong, rather than just saying
      that on occasion I'm not as good with my agile design skills as my BUFD
      skills.

      > Ron Jefferies, at the agile conference in Toronto gave a pretty decent
      > breakfast talk about not giving up everything that you used to do before
      > agility came along (like debugging, exploratory testing, usability, etc) and
      > just because you use the debugger, that doesn't mean that you aren't agile.
      > I like to think that just because you do architecture, that you can still be
      > agile. I just don't see a whole picture of what that means yet.

      Oh, I'd agree. I do architecture all the time. It's fun! I have
      architecture sketches for vast, globe-spanning systems that I hope one
      day to build. They are purely and gloriously speculative. And when I
      start new projects, I often imagine what it might look like at scale.

      But when I sit down and start coding, I try to let go of all those
      visions. I don't always succeed, but so far things seem to turn out
      better when I do. Eventually I'm sure I'll find the limits of that
      approach, but I haven't hit them yet.

      William

      --
      William Pietri <william@...>
    • Kent Beck
      Having recently finished a house, I would say that building a house is a design and construction activity. The Design/Build movement among large-scale
      Message 107 of 107 , May 7, 2005
      • 0 Attachment
        Having recently finished a house, I would say that building a house is a
        design and construction activity. The Design/Build movement among
        large-scale construction takes advantage of interleaving design and
        construction: www.dba.org.

        Kent Beck
        Three Rivers Institute

        > -----Original Message-----
        > From: extremeprogramming@yahoogroups.com
        > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of John
        > D. Mitchell
        > Sent: Thursday, May 05, 2005 1:27 PM
        > To: extremeprogramming@yahoogroups.com
        > Subject: Re: [XP] Basement decisions
        >
        > >>>>> "Shane" == Shane Mingins <shanemingins@...> writes:
        > [...]
        >
        > > Is building a house a production activity or a development
        > activity? I
        > > would have thought it a production activity and hence the metaphor
        > > inappropriate.
        >
        > Common thinking is that house building is a construction activity.
        >
        > Alas, a lot of common thinking is that software development is also
        > (just/mostly) a construction activity, too.
        >
        > I find it intriguing that the folks who are actually pushing
        > the limits in
        > the building industry (big bridges, monster skyscrapers,
        > artsy fartsy jobs
        > (that's a technical term :-), etc.) are more and more
        > approaching their
        > constructions as living systems. That is, they are seeing
        > more and more of
        > the construct as being dynamic and they are building their systems
        > accordingly.
        >
        > Of course, the best craftspersons have always seen that.
        >
        > Take care,
        > John "Base-a-ball bean berry-berry gud 2 me" Mitchell
        >
        >
        >
        > To Post a message, send it to: extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to:
        > extremeprogramming-unsubscribe@...
        >
        > ad-free courtesy of objectmentor.com
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.