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

Re: [XP] Re: Enterprise Architecture

Expand Messages
  • Brandon Campbell
    Reading your posts I think I have been where you are at, unfortunatly I couldn t convince those around me that what was going on around me was bad. I finally
    Message 1 of 18 , Nov 1, 2005
    • 0 Attachment
      Reading your posts I think I have been where you are at, unfortunatly I
      couldn't convince those around me that what was going on around me was bad.
      I finally left. A little background I have was writting Java base EJB apps
      before they was a J2EE spec, but it just became too much, and from what I
      know of the .net framework, at least apps that people think they need to
      write on top of it, these so called 'Enterprise Apps' it isn't much better.
      But XP, and TDD, they try to simplify all that, it doesn't mean you won't
      end up with the same Application, but I would be willing to bet you won't
      have the same mess. I know I don't have the same messes to deal with(of
      course that may be because I stay away from most things J2EE and keep things
      as simple as they need to be which means I have yet to write an EJB).

      as an example I have a JSP web app that the president of the company needed
      some numbers pulled out of the database. I have also been wanting to learn
      Ruby(I had picked up the pickaxe book 2 weeks ago and still hadn't started
      reading). By the end of the weekend I had a script that runs everynight that
      extracts his data into a csv file. 3 files less than 50 lines of code.

      Simple is better.

      On 11/1/05, Dennis van der Stelt <dvdstelt@...> wrote:
      >
      > > You know, the XP/TDD way of building apps isn't something that is so
      > > easy to learn about by thinking up cases to run thought experiemnts
      > > on: it's a matter of praxis more than principle. 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. But if you do that, keep an
      > > dopen mind and, as the man says, "prepare to be astonished!"
      >
      > I'll definitly have to do that. Talk face to face with some experienced
      > XP'rs.
      >
      > You know, while I'm talking to you guys, reading your arguments, I'm
      > starting to believe more and more of what I (or we) did, was wrong
      > from the start.
      >
      > At our company we've got a framework with some *great* functionality
      > in it. Won't go into details of what it is, but fact is, it has never
      > been used. NEVER! And thousands of hours have been put into it to
      > create it.
      >
      > But it's like a mindshift I have to get through. And I still don't
      > know if you're right about everything ;-) It's hard to believe and
      > especially hard to sell that you don't need a lot of stuff up front,
      > like design. But even more this counts for components that you don't
      > have yet, but (think) you know you're going to need. It's easy to call
      > yagni, but convinsing colleagues, managers, clients, etc, that all
      > this 100% design and implementing components before actually needing
      > them isn't the right way. That's hard. As I said, it's hard convinsing
      > myself! ;-)
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com <http://objectmentor.com>
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >


      --
      Brandon Campbell


      [Non-text portions of this message have been removed]
    • jgo456
      ... Such things are scarce in the hinterlands. The local Economic Development Council was recently publicizing their attempt to get a maker of air compressors
      Message 2 of 18 , Nov 1, 2005
      • 0 Attachment
        > 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.
        The local Economic Development Council was recently
        publicizing their attempt to get a maker of air
        compressors to locate a plant here as a "high tech"
        coup.

        Things in the Valley or even Rt. 128 or the twin
        cities and such still have a lot more high tech and
        computer activity than the rest of the country.

        We don't have weekly VC panel presentations,
        networking groups, MUGs, nanotech fetes, or
        local XP groups.

        north of Sopchoppy
        http://www.kermitrose.com/econ.html
      • 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 3 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 4 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 5 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 6 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 7 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.