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

RE: [XP] Architecture

Expand Messages
  • Charlie Poole
    Glen, ... It s a general pattern I learned as a boy scout - works for wooded hills, marshes, deserts, mountains or whatever. Substitute river, ridge line, tree
    Message 1 of 221 , May 1, 2002
      Glen,

      > Interesting analogy with hiking. Since we live in the mountains and spend
      > most of the warm days on trails you're concept is very good. We don't have
      > much in the way of woods, since nearly everything worth going to is above
      > timber line. But the "search" pattern for peak-to-peak hikes
      > works much the
      > same way. The true bearing is not worth much, but a relative
      > bearing to the
      > next peak that will land us to a "known" side of the mountain, then an
      > adjustment from there to the summit.

      It's a general pattern I learned as a boy scout - works for wooded hills,
      marshes, deserts, mountains or whatever. Substitute river, ridge line,
      tree line, etc for the road.

      > >Based on your comments in other threads, I suspect this is what you're
      > >doing. You seem to be a bit heavy on architecture as compared to many
      > >other folks here, but it sounds as if you're tons lighter than other
      > >people doing similar things.
      >
      > I rationalize this as a domain influence, since in the ERP world many
      > decisions are irrevocable, erring on the heavy side produces
      > lower risk than
      > moving forward only to discover there is missing information. To
      > stretch the
      > analogy a bit, hiking in the mountains can have disastrous results - death
      > at times - if one is not prepared for all events, even those that
      > seem very
      > unlikely to flatlanders. It's snowing as I type on what was a nice spring
      > day yesterday. Wouldn't want to be on the side of Niwot Ridge
      > http://culter.colorado.edu:1030/exec/sdlmetpage.pl.

      Hey wait a minute! That's *my* analogy. :-)

      Back in the software development world, I'd like to spell out a distinction
      which you're familiar with but hasn't shown up in this thread yet. I have
      some
      experience with systems that can have serious consequences if done wrong -
      up
      to and including death. Doing *good* design and planning is essential to
      reducing those risks. Doing *more* does not necessarily have the same
      affect,
      although it is sometimes useful to those who want to avoid the risk of being
      *blamed* for failure.

      Charlie Poole
      cpoole@...


      I know you know the difference, but
    • li jian@InfoQ
      Hi, Recommend several articles: http://www.infoq.com/news/2007/07/AgileBadForDesign http://www.infoq.com/news/2007/09/AM_and_EA
      Message 221 of 221 , Nov 20, 2007
        Hi,

        Recommend several articles:

        http://www.infoq.com/news/2007/07/AgileBadForDesign
        http://www.infoq.com/news/2007/09/AM_and_EA
        http://www.infoq.com/articles/release-it-five-am

        Br

        Li Jian


        --
        长空净,
        一枕梦尽风露寒。
        风露寒,
        新痴旧恨,今古一般。

        长是月圆人千里,
        凭栏人暗伤流年。
        伤流年,
        从今几度,星移物转。


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.