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

Re: Enterprise Architecture

Expand Messages
  • Keith Braithwaite
    ... The where? The what? The which? ... Believe me, we don t have these in Dorset, either. Neither did we have them in Cumbria, my base before I moved down
    Message 1 of 18 , Nov 1, 2005
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "jgo456" <jgo456@y...> wrote:
      >
      > > In extremeprogramming@yahoogroups.com, "Keith Braithwaite" <
      > Keith.Braithwaite@w...> wrote:
      > > If you want to know what it's like and how
      > > to do it, go along to an immersion course, or
      > > a local XP group, and just give it a try.
      >
      > Such things are scarce in the hinterlands.[...]
      >
      > Things in the Valley or even Rt. 128 or the twin
      > cities
      The where? The what? The which?

      > We don't have weekly VC panel presentations,
      > networking groups, MUGs, nanotech fetes,
      Believe me, we don't have these in Dorset, either. Neither did we have
      them in Cumbria, my base before I moved down here (via Singapore)

      > or
      > local XP groups.
      Well, why not? It might be that you're the only one in your area
      interested in XP, but I kind-of doubt it. Got a college of university
      with a computing department anywhere nearby? Away you go. Gather a few
      interested souls and invite a guest speaker.

      Keith
    • William Pietri
      ... Hi, Dennis! Having faced similar problems before, here s my advice: Do as much planning and documentation-writing as you need to convince yourself that
      Message 2 of 18 , Nov 1, 2005
      • 0 Attachment
        Dennis van der Stelt wrote:

        >Hi there,
        > I'm totally new to XP and perhaps this belongs in the TDD group. But I
        >might as well start here.
        > No BDUF. But when I have an enterprise application that will spawn on a
        >server farm, has hard performance requirements, must use stuff like
        >localization, MVC/MVP patterns, etc, etc.
        > How would I take this on? Would I create a proof of concept first or would
        >I just start writing tests? Would I create a document on what I want to do
        >and try some things out, or ... do I just start writing tests?
        >
        >

        Hi, Dennis! Having faced similar problems before, here's my advice:

        Do as much planning and documentation-writing as you need to convince
        yourself that there is at least one plausible way to build the system
        you want. If there's a fair bit of money involved, it's not unreasonable
        to be able to convince others (and yourself) that you can do this.

        Then take all of that documentation and lock it in the bottom of some
        out-of-the-way file cabinet. Mentally let go of it. Then spend a few
        days doing a big planning game. Make sure to state all of those things
        you mention above as story cards. That even goes for performance and
        scale.. And then start producing a new version every week. If you ever
        get completely stuck for a design, you can always go back to your
        original plans for inspiration. But I'll bet that you won't.

        As for trying things out, In XP there's something known as a spike: when
        you can't estimate a card but need to put a number on it, you build just
        enough of a prototype that you can estimate things. Instead of one giant
        proof-of-all-your-concepts, you build a number of
        proof-of-a-single-concept items as tactically necessary. You will end up
        needing fewer of those than you now expect.

        If you're used to doing things with a lot of paper, it can be pretty
        scary to just set it all aside. But having gone through the complete XP
        process several times now, I vastly prefer it. At the beginning of the
        project, I know less than I ever will. By saving my design work until I
        knew as much as possible, I've ended up with software that's simpler,
        faster, and cheaper. And by not designing the things that I ended up not
        building, I got to focus my efforts on things that really mattered.

        William
      • Dennis van der Stelt
        Thanks, that s a really good advise! I ll have to try that some day, creating documentation to satisfy my primal instinct to create documentation, as well as
        Message 3 of 18 , Nov 2, 2005
        • 0 Attachment
          Thanks, that's a really good advise! I'll have to try that some day,
          creating documentation to satisfy my primal instinct to create
          documentation, as well as that of my manager(s). Then just put it away
          and start the project with XP principles.

          The tiny bits of proof-of-concept I was already working out. Not only
          for me, but also for my colleagues to figure out what I was doing in
          there. Having one large POC often confuses people.

          Thanks again,
          Dennis

          On 11/2/05, William Pietri <william@...> wrote:
          > Dennis van der Stelt wrote:
          >
          > >Hi there,
          > > I'm totally new to XP and perhaps this belongs in the TDD group. But I
          > >might as well start here.
          > > No BDUF. But when I have an enterprise application that will spawn on a
          > >server farm, has hard performance requirements, must use stuff like
          > >localization, MVC/MVP patterns, etc, etc.
          > > How would I take this on? Would I create a proof of concept first or would
          > >I just start writing tests? Would I create a document on what I want to do
          > >and try some things out, or ... do I just start writing tests?
          > >
          > >
          >
          > Hi, Dennis! Having faced similar problems before, here's my advice:
          >
          > Do as much planning and documentation-writing as you need to convince
          > yourself that there is at least one plausible way to build the system
          > you want. If there's a fair bit of money involved, it's not unreasonable
          > to be able to convince others (and yourself) that you can do this.
          >
          > Then take all of that documentation and lock it in the bottom of some
          > out-of-the-way file cabinet. Mentally let go of it. Then spend a few
          > days doing a big planning game. Make sure to state all of those things
          > you mention above as story cards. That even goes for performance and
          > scale.. And then start producing a new version every week. If you ever
          > get completely stuck for a design, you can always go back to your
          > original plans for inspiration. But I'll bet that you won't.
          >
          > As for trying things out, In XP there's something known as a spike: when
          > you can't estimate a card but need to put a number on it, you build just
          > enough of a prototype that you can estimate things. Instead of one giant
          > proof-of-all-your-concepts, you build a number of
          > proof-of-a-single-concept items as tactically necessary. You will end up
          > needing fewer of those than you now expect.
          >
          > If you're used to doing things with a lot of paper, it can be pretty
          > scary to just set it all aside. But having gone through the complete XP
          > process several times now, I vastly prefer it. At the beginning of the
          > project, I know less than I ever will. By saving my design work until I
          > knew as much as possible, I've ended up with software that's simpler,
          > faster, and cheaper. And by not designing the things that I ended up not
          > building, I got to focus my efforts on things that really mattered.
          >
          > William
          >
          >
          >
          > 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
          >
          >
          >
          >
          >
          >
          >
          >
        • Steven Gordon
          Well-factored code and automated tests should communicate better what your POC is doing and how than detailed documents. If it doesn t then work on improving
          Message 4 of 18 , Nov 2, 2005
          • 0 Attachment
            Well-factored code and automated tests should communicate better what your
            POC is doing and how than detailed documents. If it doesn't then work on
            improving the clarity of the code and the design instead of covering over
            the problem with documentation. A very brief overview document is not
            discouraged.
            The main point in putting away the documentation is to avoid having to
            choose between abiding by it or keeping it up to date as the design changes.
            Either way, you end up resisting change instead of embracing it.

            On 11/2/05, Dennis van der Stelt <dvdstelt@...> wrote:
            >
            > Thanks, that's a really good advise! I'll have to try that some day,
            > creating documentation to satisfy my primal instinct to create
            > documentation, as well as that of my manager(s). Then just put it away
            > and start the project with XP principles.
            >
            > The tiny bits of proof-of-concept I was already working out. Not only
            > for me, but also for my colleagues to figure out what I was doing in
            > there. Having one large POC often confuses people.
            >
            > Thanks again,
            > Dennis
            >


            [Non-text portions of this message have been removed]
          • William Pietri
            ... I d agree that those are benefits, but for me the main point in putting away my initial design documents is to clear my head of my preconceptions. I find
            Message 5 of 18 , Nov 2, 2005
            • 0 Attachment
              Steven Gordon wrote:

              >Well-factored code and automated tests should communicate better what your
              >POC is doing and how than detailed documents. If it doesn't then work on
              >improving the clarity of the code and the design instead of covering over
              >the problem with documentation. A very brief overview document is not
              >discouraged.
              > The main point in putting away the documentation is to avoid having to
              >choose between abiding by it or keeping it up to date as the design changes.
              >Either way, you end up resisting change instead of embracing it.
              >
              >

              I'd agree that those are benefits, but for me the main point in putting
              away my initial design documents is to clear my head of my
              preconceptions. I find that having the old ideas too handy inclines me
              to follow them instead of dealing with situation I'm in now.

              William
            Your message has been successfully submitted and would be delivered to recipients shortly.