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

Enterprise Architecture

Expand Messages
  • Dennis van der Stelt
    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
    Message 1 of 18 , Oct 31, 2005
    • 0 Attachment
      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]
    • 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 2 of 18 , Oct 31, 2005
      • 0 Attachment
        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 3 of 18 , Oct 31, 2005
        • 0 Attachment
          --- 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 4 of 18 , Oct 31, 2005
          • 0 Attachment
            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 5 of 18 , Oct 31, 2005
            • 0 Attachment
              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 6 of 18 , Oct 31, 2005
              • 0 Attachment
                --- 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 7 of 18 , Oct 31, 2005
                • 0 Attachment
                  @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 8 of 18 , Oct 31, 2005
                  • 0 Attachment
                    > @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 9 of 18 , Oct 31, 2005
                    • 0 Attachment
                      --- 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 10 of 18 , Oct 31, 2005
                      • 0 Attachment
                        > 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 11 of 18 , Oct 31, 2005
                        • 0 Attachment
                          > 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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.