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

RE: [XP] Architectural decisions (was Re: XP's Achilles' Heel)

Expand Messages
  • Booch, Grady
    First, I can agree that a significant decision is one that has a high associated cost, but I can t see that cost as necessarily associated with *changing*
    Message 1 of 176 , Apr 26, 2002
      First, I can agree that a "significant" decision is one that has a high
      associated cost, but I can't see that cost as necessarily associated
      with *changing* the decision. A wrong decision can be costly, and
      failing to reverse that decision can turn out to be even more costly.
      My experience is limited, but I've seen that happen a lot in my short
      time in the industry.

      [egb> ] I agree with you: sometimes there are real costs that derive from
      changing significant design decisions (e.g., all real stories: the
      encryption mechanism the team devised just didn't reach the desired
      performance for the system but markedly changing the way messages flowed
      through the system, albeit a change that ripped through the entire system,
      changed the system's behavior sufficiently so that performance became
      tolerable; vendor X upon whom you this team relied for a key database
      component just went dot bomb and they had to rip things up to replace it)
      and sometimes there are hidden costs from bad design decisions that for
      whatever reason you stuck with (e.g. also real: the UI was so crappy that
      customers walked away in droves, eventually collapsing the market for this

      Is this, under a different guise, a version of the "cost of change"
      argument ? This would help us be clearer about the gap between
      viewpoints, since it is said that XP rejects the traditional view that
      change becomes more expensive as early decisions become ever
      more entrenched.

      [egb> ] My personal experience as well as all of the formal studies I have
      encountered supports the view that change becomes more expensive as early
      decisions become ever more entrenched. This is why we have the RUP world
      view of architecture first (but also allowing the architecture to grow with
      each successive release).

      [egb> ] For example, I was working with the architect at a large Swiss bank,
      formed from the merger of two large banks. There were two business
      pressures: merge the two bank's systems and also move to an architecture
      that would permit more services to end users and peer banks over the web.
      The team chose Websphere (a significant design decision that would be costly
      to change out, not just because of technical issues but training,
      deployment, and installation issues) but even then, the semantic gap between
      Websphere and what they had to deliver was significant. They had business
      experts who knew all the arcane rules of currency exchange and international
      money transfer...these folks were not going to become programmers, so the
      key was to bring the platform to them by devising a set of architectural
      mechanisms that bridged that gap. Those mechanisms were also significant
      design decisions (by the way, it was the use cases that shaped these
      mechanisms) and a small architecture team was to develop AND VALIDATE those
      mechanisms before unleashing the whole team upon them. In the broad rhythm
      of the project, this was indeed an intentional architecture first decision,
      because the cost of changing these decisions as well as the cost of making
      wrong decisions at this point was simply too high. Architecture first
      essentially says to attack the key technical risks of a system early,
      wrestle them to the ground, and then, once established, improve upon then.

      It seems to me, by the way, that XP doesn't claim that an
      entrenched decision isn't expensive, but that decisions *do not*
      have to become entrenched as much as we imagine.

      [egb> ] That is not a position that is exclusively XP: it's simply an issue
      of software economics that even the RUP embraces: there is a cost and a risk
      associated with change (and with deciding to not change) and it is a
      business planning decision to weigh off those costs. An iterative process
      that sets the rhythm of a project by continuously releasing executables
      offers discrete baselines against which midcourse corrections may be made:
      you may choose to change some things in a particular release, but may defer
      others to a later one...the key being that you intentionally and actively
      manage change.

      The second issue is with the architect role, and it is a human one -
      what if people who take on the architect's mantle come to view their
      own mission as "making expensive decisions" ? I can readily see
      how some people might infer that from your above remark, in fact it
      nearly seemed to me as if you'd been saying that.

      [egb> ] None of the quality architects I have had the pleasure of working
      with ever took on that mantle: rather, their mission was consistently viewed
      as that of an engineering effort to trade off the forces weighing upon the
      team and deliver great software.

      I would expect such a perception to be counter-productive, since an
      architect would tend to reject cheap decisions, or cost-effective
      ones, as not appropriate to protect her professional identity. And the
      more expensive the decisions, the harder it would be to change
      them later, thus making the situation self-reinforcing.

      [egb> ] My experience is that natural selection takes place: I rarely see
      arrogant, alpha male/female architects like that survive for very long. A
      development team and its members are ultimately judged upon delivering great
      software in a timely and efficient manner. Office games such as this - at
      any level, not just the architect - are counterproductive to that goal.

      [egb> ] The notion of egoless programming has been around for a long time,
      and to its credit, as I interpret it, XP helps to institutionalize that
      notion. However, laws cannot dictate morality, and so while process can
      help, humans will be humans. Insecure coders will grab on to the power they
      have and so be less that productive in pair development; ego-filled
      developers will rail against the everyone-can-touch-the-code philosophy in
      subtle yet counterproductive ways.

      And again, in spite of being a relative newcomer to the field, I've
      seen many people take exactly the wrong-headed approach to
      architecture implied above : "My budget is bigger than yours, *I*
      always use Oracle products." (It always baffles me to hear people
      bragging that they have led *very* *large* projects, when they then
      go on to describe functionality that sounds like two people in a
      garage could have shipped it earlier.)

      [egb> ] Among alpha males, size does matter, even in software...
    • J. B. Rainsberger
      ... I can appreciate that problem. Can you help strengthen any of those chains? Can we help you do that? ... J. B. (Joe) Rainsberger :: http://www.jbrains.ca
      Message 176 of 176 , Nov 8, 2008
        On 2008-11-02, at 09:42 , Mike Coon wrote:
        > Yes I can. I am working toward a pull system - right now all the
        > links in
        > the chains are weak in some way.
        I can appreciate that problem. Can you help strengthen any of those
        chains? Can we help you do that?
        J. B. (Joe) Rainsberger :: http://www.jbrains.ca
        Your guide to software craftsmanship
        JUnit Recipes: Practical Methods for Programmer Testing
        2005 Gordon Pask Award for contributions to Agile Software Practice
      Your message has been successfully submitted and would be delivered to recipients shortly.