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

Re: [XP] Enterprise Architecture

Expand Messages
  • 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 1 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 2 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 3 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 4 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.