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

Re: [XP] Deferring decisions (Re: Architecture)

Expand Messages
  • Jim Standley
    Our official process was to identify any technical risk as early as possible and do a minimal proof of concept. If the PoC was successful, we might clean up
    Message 1 of 1 , Apr 30, 2002
    • 0 Attachment
      Our official process was to identify any technical risk as early as possible
      and do a minimal proof of concept. If the PoC was successful, we might
      clean up the code and integrate it, or just record the outcome for later.
      In this case, we would have caught the missing driver earlier and had a
      better opportunity to run through company channels to get one. Our excuse
      (not a good reason) for being so late was the other project didn't have a
      database for us to test with. As it was, we found a driver written in
      Germany and a manager bought it on the Internet with his credit card. If we
      require any support, or even get an audit for non-approved software, we will
      get slapped fer sure.

      Just an interesting note on this problem: Sun support had zilch in their
      knowledge base about connecting to Sybase from Java on Solaris. Sheesh.
      Our client rep eventually called back to ask how we solved it in case
      somebody else asks.

      ----- Original Message -----
      From: "J. B. Rainsberger" <jbr@...>
      To: <extremeprogramming@yahoogroups.com>
      Sent: Tuesday, April 30, 2002 12:34 PM
      Subject: [XP] Deferring decisions (Re: Architecture)


      > Quoting extremeprogramming@yahoogroups.com:
      > > From: "Jim Standley" <J_Standley@...>
      > > Subject: Re: Architecture
      >
      > > I'm interested in the notion of deferring architectural decisions. I
      > > assume
      > > that is so you can learn more about the whole system before making
      > > commitments?
      >
      > Yes. It is also possible to learn so much about a system that the need to
      make
      > a decision or a commitment goes away. This is another instance of YAGNI.
      >
      > <snip />
      >
      > > Example where I got burned lately ... Another system's API is to call
      > > their
      > > stored procedures. We assumed this is simple and focused on other
      > > things.
      > > Then late in the schedule we found we had no approved Sybase driver for
      > > Java
      > > on Solaris. By deferring the driver decision, we nearly blew the
      > > delivery
      > > schedule.
      > >
      > > Does that make sense?
      >
      > It sounds like you deferred gathering options rather than deferring a
      decision.
      > I wonder whether the XP community at large has ever made this distinction
      > before -- or at least, pointed the distinction out. YAGNI tells us not to
      build
      > ahead, but it does not tell us not to *think* ahead. This is likely a
      situation
      > where you needed to learn about the alternatives, even if a decision
      wasn't
      > required at the time. You at least needed to verify your assumption that
      using
      > that system's API was simple: a spike would have handled the job nicely.
      >
      > What decisions would you have made differently had you known about this at
      the
      > earliest possible moment in the schedule?
      >
      > J. B. (Joe) Rainsberger
      > President, Diaspar Software Services
      > http://www.diasparsoftware.com
      > Let's write software that people understand.
      >
      > PS: No matter what you do, there will always be surprises.
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.