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

Re: [XP] Enterprise Architecture

Expand Messages
  • Steven Gordon
    If you can express the enterprise level requirements as tests, that is certainly better than expressing them as documents. If the enterprise architecture
    Message 1 of 18 , Oct 31, 2005
      If you can express the enterprise level requirements as tests, that is
      certainly better than expressing them as documents.
      If the enterprise architecture already has reusable components that promote
      the corporate architectural values, you should make sure you leverage those
      components instead of reinventing the wheel in your project. Becoming aware
      of these components and what they do and do not provide would constitute
      some up front work that would be justifiable in my opinion. Just time-box
      such up front exploratory work to keep it as lean as possible.

      On 10/31/05, Dennis van der Stelt <dvdstelt@...> 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?
      > Thanks in advance,
      > Dennis van der Stelt
      >


      [Non-text portions of this message have been removed]
    • Keith Braithwaite
      ... How did you arrive at the belief that you need these things? OK, genuine needs for I18N and L10N are fairly easy to spot, but why an enterprise app? Why a
      Message 2 of 18 , Oct 31, 2005
        --- In extremeprogramming@yahoogroups.com, Dennis van der Stelt
        <dvdstelt@g...> wrote:

        > 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 did you arrive at the belief that you need these things?

        OK, genuine needs for I18N and L10N are fairly easy to spot, but why
        an enterprise app? Why a server farm?

        Are you hard performance targets well founded on a business case with
        realistic projections for size of user base etc, or are they
        .com-style fantasy? Believe me, if it's the second and not the first
        you *will* come to regret pushing in a load of "scalability"
        enterprise voodoo. (And maybe in the first case, too ;-)

        Keith
      • Dennis van der Stelt
        I ve had my share of applications to kind of know when an application needs what. Because of multiple issues, you cannot always take the previously build
        Message 3 of 18 , Oct 31, 2005
          I've had my share of applications to kind of know when an application needs
          what. Because of multiple issues, you cannot always take the previously
          build components into a new project.
          But I can come up with some examples.
          1) I need to build a data-driven application with some reports and the
          ability to create reports in Excel. Multiple companies will use it, as it's
          a product being sold by our client. Me and my client are based on Microsoft
          technology and know this stuff. So I can choose between webbased and a
          smartclient application. As it's data-entry-driven I chose smartclient. This
          means webservices, a sql database, wse 3.0 as security has to be tight. Etc,
          etc. I'll use VSTO to provide the link between my Windows App and Office
          2003. I'll use ASP.NET <http://ASP.NET> for my webservices.
          2) Consider the same application with some functionality web-based. Now I
          do need something like an MVC/MVP pattern, because my app won't be any
          easier to maintain not using it. I can already begin imagining simple
          business logic like how long my password must be. I'll have it in database,
          asp.net <http://asp.net> web client, asp.net <http://asp.net> webservice,
          winclient and business layer. That's just the smallest problem.
          3) For this project I won't have a lot of clients, but think about me being
          sure having lots and lots of clients. Then I must make sure the webservices
          will be able to handle the load. Perhaps do some multi-threading stuff,
          a-synchronous, etc, etc, to be sure it'll keep working.
          Now in what way do I go ahead and prove to myself and my client that this
          will work? I mean, some of these options cannot just be created by doing it
          the simplest way and then just build in all this stuff. Am I wrong here? I'm
          not the one with experience! :-)
          Please tell me, in what way do I think ahead of this? What will I take into
          considiration? I mean, refactoring is one thing, changing my entire
          application architecture because I suddenly feel my clients must wait 4
          hours just to get a result because my server is bogging up? How do _you_
          explain these things to clients? "Hey, I'll refactor your application a bit
          here and there. It'll take like 60 days, but I have to write tests first.
          You understand, don't you?" ;-)
          I'm really really curious! :)
          Thanks for your patience with me, ;-)
          Dennis


          On 10/31/05, Keith Braithwaite <Keith.Braithwaite@...> wrote:
          >
          > --- In extremeprogramming@yahoogroups.com, Dennis van der Stelt
          > <dvdstelt@g...> wrote:
          >
          > > 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 did you arrive at the belief that you need these things?
          >
          > OK, genuine needs for I18N and L10N are fairly easy to spot, but why
          > an enterprise app? Why a server farm?
          >
          > Are you hard performance targets well founded on a business case with
          > realistic projections for size of user base etc, or are they
          > .com-style fantasy? Believe me, if it's the second and not the first
          > you *will* come to regret pushing in a load of "scalability"
          > enterprise voodoo. (And maybe in the first case, too ;-)
          >
          > Keith
          >


          [Non-text portions of this message have been removed]
        • Steven Gordon
          Have your customers (including whoever is paying you) prioritize the various business and enterprise requirements (as stories with clear business value and
          Message 4 of 18 , Oct 31, 2005
            Have your customers (including whoever is paying you) prioritize the various
            business and enterprise requirements (as stories with clear business value
            and estimated implementation costs), tackle them in order of the given
            priorities, and use good OO design and programming practices to keep the
            code clean and modular enough to make it easy to adapt to whatever
            architecture becomes necessary when it becomes necessary. Such refactorings
            should not take even a small fraction of the 60 days you suggest, and the
            unit tests should not have to be rewritten.
            The only variance to this approach in the enterprise context is the
            leveraging of existing enterprise level components instead of implementing
            the same functionality yourself, especially if there is (or will be) a
            mandate to do so.

            On 10/31/05, Dennis van der Stelt <dvdstelt@...> wrote:
            >
            > I've had my share of applications to kind of know when an application
            > needs
            > what. Because of multiple issues, you cannot always take the previously
            > build components into a new project.
            > But I can come up with some examples.
            > 1) I need to build a data-driven application with some reports and the
            > ability to create reports in Excel. Multiple companies will use it, as
            > it's
            > a product being sold by our client. Me and my client are based on
            > Microsoft
            > technology and know this stuff. So I can choose between webbased and a
            > smartclient application. As it's data-entry-driven I chose smartclient.
            > This
            > means webservices, a sql database, wse 3.0 as security has to be tight.
            > Etc,
            > etc. I'll use VSTO to provide the link between my Windows App and Office
            > 2003. I'll use ASP.NET <http://ASP.NET> <http://ASP.NET> for my
            > webservices.
            > 2) Consider the same application with some functionality web-based. Now I
            > do need something like an MVC/MVP pattern, because my app won't be any
            > easier to maintain not using it. I can already begin imagining simple
            > business logic like how long my password must be. I'll have it in
            > database,
            > asp.net <http://asp.net> <http://asp.net> web client, asp.net<http://asp.net><
            > http://asp.net> webservice,
            > winclient and business layer. That's just the smallest problem.
            > 3) For this project I won't have a lot of clients, but think about me
            > being
            > sure having lots and lots of clients. Then I must make sure the
            > webservices
            > will be able to handle the load. Perhaps do some multi-threading stuff,
            > a-synchronous, etc, etc, to be sure it'll keep working.
            > Now in what way do I go ahead and prove to myself and my client that this
            > will work? I mean, some of these options cannot just be created by doing
            > it
            > the simplest way and then just build in all this stuff. Am I wrong here?
            > I'm
            > not the one with experience! :-)
            > Please tell me, in what way do I think ahead of this? What will I take
            > into
            > considiration? I mean, refactoring is one thing, changing my entire
            > application architecture because I suddenly feel my clients must wait 4
            > hours just to get a result because my server is bogging up? How do _you_
            > explain these things to clients? "Hey, I'll refactor your application a
            > bit
            > here and there. It'll take like 60 days, but I have to write tests first.
            > You understand, don't you?" ;-)
            > I'm really really curious! :)
            > Thanks for your patience with me, ;-)
            > Dennis
            >
            >
            > On 10/31/05, Keith Braithwaite <Keith.Braithwaite@...> wrote:
            > >
            > > --- In extremeprogramming@yahoogroups.com, Dennis van der Stelt
            > > <dvdstelt@g...> wrote:
            > >
            > > > 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 did you arrive at the belief that you need these things?
            > >
            > > OK, genuine needs for I18N and L10N are fairly easy to spot, but why
            > > an enterprise app? Why a server farm?
            > >
            > > Are you hard performance targets well founded on a business case with
            > > realistic projections for size of user base etc, or are they
            > > .com-style fantasy? Believe me, if it's the second and not the first
            > > you *will* come to regret pushing in a load of "scalability"
            > > enterprise voodoo. (And maybe in the first case, too ;-)
            > >
            > > Keith
            >


            [Non-text portions of this message have been removed]
          • Keith Braithwaite
            ... as it s ... Microsoft ... smartclient. This ... tight. Etc, ... [...] ... that this ... Well, you seem to be pretty confident that you know that this is
            Message 5 of 18 , Oct 31, 2005
              --- In extremeprogramming@yahoogroups.com, Dennis van der Stelt
              <dvdstelt@g...> wrote:

              > 1) I need to build a data-driven application with some reports and the
              > ability to create reports in Excel. Multiple companies will use it,
              as it's
              > a product being sold by our client. Me and my client are based on
              Microsoft
              > technology and know this stuff. So I can choose between webbased and a
              > smartclient application. As it's data-entry-driven I chose
              smartclient. This
              > means webservices, a sql database, wse 3.0 as security has to be
              tight. Etc,
              > etc. I'll use VSTO to provide the link between my Windows App and Office
              > 2003. I'll use ASP.NET <http://ASP.NET> for my webservices.
              [...]
              > Now in what way do I go ahead and prove to myself and my client
              that this
              > will work?
              Well, you seem to be pretty confident that you know that this is the
              right technology set, so who are you trying to convince?

              If you want to de-risk the project then you could write an end-to-end
              test that demonstrates all these bits and bobs talking to each other.
              I would.

              > How do _you_
              > explain these things to clients? "Hey, I'll refactor your
              application a bit
              > here and there. It'll take like 60 days, but I have to write tests
              first.
              > You understand, don't you?" ;-)
              Well, I never want to do that, so I never have to have that
              conversation. In fact, I don't explain to clients that I'm going to
              refactor, because refactoring is part of my working practice and not
              negotiable with them.

              Again, you seem very sure of your technology solution, so what would
              you be expecting to change?

              Keith
            • Dennis van der Stelt
              @Keith : Hmmm, maybe I gave the wrong example after all ;-) But I guess normally people would create some sort of framework before they begin developing their
              Message 6 of 18 , Oct 31, 2005
                @Keith : Hmmm, maybe I gave the wrong example after all ;-)
                But I guess normally people would create some sort of framework before they
                begin developing their app. Kind of a proof of concept, but the framework is
                worked out completely. Then you can run performance tests on those, etc.
                Can it happen that with TDD, you oversee something and you have to thrown
                your initial stuff overboard, or at least a large part? I mean, TDD is
                great, I believe that, but it can't solve every problem in the universe.
                Haven't you ever experienced something like that? If not, why not? What did
                you do up front?
                Thanks for your patience with me! :)
                Dennis


                [Non-text portions of this message have been removed]
              • Ramon Leon
                ... People who write frameworks before they write the app to run on it, are bad at writing frameworks. Good frameworks are created through refactoring out
                Message 7 of 18 , Oct 31, 2005
                  > @Keith : Hmmm, maybe I gave the wrong example after all ;-)
                  > But I guess normally people would create some sort of
                  > framework before they begin developing their app. Kind of a
                  > proof of concept, but the framework is worked out completely.

                  People who write frameworks before they write the app to run on it, are
                  bad at writing frameworks. Good frameworks are created through
                  refactoring out duplication from several existing applications, the
                  applications need to come first. You shouldn't start a project by
                  writing a framework, you should start writing the application instead.
                • Keith Braithwaite
                  ... before they ... framework is ... thrown ... Every time I ve fallen into the trap of thinking that I can work out a framework completely before I begin
                  Message 8 of 18 , Oct 31, 2005
                    --- In extremeprogramming@yahoogroups.com, Dennis van der Stelt
                    <dvdstelt@g...> wrote:
                    >
                    > @Keith : Hmmm, maybe I gave the wrong example after all ;-)
                    > But I guess normally people would create some sort of framework
                    before they
                    > begin developing their app. Kind of a proof of concept, but the
                    framework is
                    > worked out completely. Then you can run performance tests on those, etc.
                    > Can it happen that with TDD, you oversee something and you have to
                    thrown
                    > your initial stuff overboard, or at least a large part?
                    Every time I've fallen into the trap of thinking that I can work out a
                    framework completely before I begin building an app I have ended up
                    having to throw most of it away, test-first or not.

                    However, whenever I've grown an application feature by feature using
                    TDD, I find that much of the code remains. That's not to say that all
                    the code that I write stays forever, some goes--in fact, deleting now
                    unused code is a great experience! It's one of the best refactorings.

                    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!"

                    Keith
                  • Keith Braithwaite
                    ... Yep. I m convinced that a big part of how come Ruby on Rails rocks so hard is that it was reversed out of a working application (and by developers that ate
                    Message 9 of 18 , Oct 31, 2005
                      > Good frameworks are created through
                      > refactoring out duplication from several existing applications, the
                      > applications need to come first.

                      Yep. I'm convinced that a big part of how come Ruby on Rails rocks so
                      hard is that it was reversed out of a working application (and by
                      developers that ate their own dog food for a living, at that), so
                      every feature in it was driven by the need to get something of real
                      value done.

                      And much of the reason that certain other frameworks...er...fail to
                      rock quite so hard, is that they weren't. And so are crammed with
                      stuff that some very, very smart folks somewhere talked themselves
                      into beleiving would be useful to somebody *else*, sometime.

                      Frameworks developed in the abstract seem to tend to aim for
                      completeness, and fail. Whereas reversed-out frameworks have adequacy
                      built in. Good frameworks are reusable because they have already been
                      used, bad frameworks are built to exhibit the abstract quality of
                      "reusability" and end up being very little use at all. Bah!

                      Keith
                    • Dennis van der Stelt
                      ... 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
                      Message 10 of 18 , Oct 31, 2005
                        > 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! ;-)
                      • 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 11 of 18 , Nov 1, 2005
                          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 12 of 18 , Nov 1, 2005
                            > 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 13 of 18 , Nov 1, 2005
                              --- 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 14 of 18 , Nov 1, 2005
                                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 15 of 18 , Nov 2, 2005
                                  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 16 of 18 , Nov 2, 2005
                                    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 17 of 18 , Nov 2, 2005
                                      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.