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

unsubscribe

Expand Messages
  • Bretz, Matt
    ... From: extremeprogramming@yahoogroups.com [mailto:extremeprogramming@yahoogroups.com] Sent: Monday, April 30, 2001 2:22 PM To:
    Message 1 of 20 , May 1, 2001
    • 0 Attachment
      -----Original Message-----
      From: extremeprogramming@yahoogroups.com
      [mailto:extremeprogramming@yahoogroups.com]
      Sent: Monday, April 30, 2001 2:22 PM
      To: extremeprogramming@yahoogroups.com
      Subject: [XP] Digest Number 1064


      To Post a message, send it to: extremeprogramming@...

      To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...

      Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods.
      Early registration discounts EXTENDED until May 1, 2001. www.xpuniverse.com
      for details and registration.
      ------------------------------------------------------------------------

      There are 25 messages in this issue.

      Topics in this digest:

      1. Re: Reuseability
      From: "Nick Fortescue" <nick@...>
      2. Re: Reuseability
      From: davechaplin@...
      3. Re: XP/R - Extreme Programming/Remote
      From: kentbeck@...
      4. Re: Re: Reuseability
      From: Dan Palanza <dan@...>
      5. Re: XP/R - Extreme Programming/Remote
      From: Ron Jeffries <ronjeffries@...>
      6. Re: Reusability
      From: Ralph Johnson <johnson@...>
      7. Studies on XP searched
      From: Astrid Schroeder <schroeda@...-muenchen.de>
      8. Re: Reuseability
      From: Kenneth Tyler <kentyler@...>
      9.
      From: "Moss, D" <dmoss@...>
      10. Re: Reuseability
      From: "Nick Fortescue" <nick@...>
      11. Re: all OO programmers should learn design patterns
      From: Andrew Hunt <andy@...>
      12. Re: Refactorings Paper
      From: lindstrom@...
      13. Developing a secure link
      From: Angus Mezick <amezick@...>
      14. Re: Reusability
      From: Kevin Smith <sent@...>
      15. Re: Developing a secure link
      From: Ron Jeffries <ronjeffries@...>
      16. Re: Developing a secure link
      From: Angus Mezick <amezick@...>
      17. Re:
      From: Ron Jeffries <ronjeffries@...>
      18. Re: Developing a secure link
      From: "Paul Gunn" <pgunn@...>
      19. Re: Re:
      From: Angus Mezick <amezick@...>
      20. Re: Reuseability
      From: azami@...
      21. Re: Studies on XP searched
      From: "Lee" <lvbis@...>
      22. Re: Studies on XP searched
      From: "Lee" <lvbis@...>
      23. Re: Re: secure programming
      From: "Nick Fortescue" <nick@...>
      24. Re: Re:
      From: wecaputo@...
      25. How to use design patterns.
      From: rmartin@...


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 1
      Date: Mon, 30 Apr 2001 10:28:11 +0100
      From: "Nick Fortescue" <nick@...>
      Subject: Re: Reuseability


      From: <mattias@...>


      > Hi!
      >
      > I am currently working with a project which is working out how
      > reusability and design patterns would increase the value of the
      > defense software projects in Sweden.
      >
      > Of course I will try to trick them into adopting some agile software
      > development process (not straight XP because of the size of the
      > projects and the addiction to a certain amount of paperwork), but the
      > thing is how to do that when the very main subject on the study is
      > REUSE.

      First comment: XP should never be about tricking (I wouldn't know about
      Defense Department politics) XP values are communication (ie honesty) and
      courage. Every project should have buy in. Present the facts, and if someone
      makes a different decision so be it.

      > One tip is to reuse the tests.
      >
      > How have you done? Are there never one single reused code-line in
      > your different XP projects?
      >
      > Can the refactorings lead to objects that are easier to reuse?
      > Or can you reuse a few objects and refactor them into a new design
      > (reuse of tests included here)?

      I'd be interested in others' feedback here. I believe refactoring and reuse
      are fundamentally opposed, which is tricky because I believe strongly in
      both of them. In much refactoring, like factoring out some functionality you
      have to change every dependence on the original code. In cases where that
      code is used in many projects that can lead to huge amounts of work, ie
      reuse makes refactoring much harder. On the other hand refactored code tends
      to be of cleaner design, and so reuse is easier.

      My attitude at the moment is that when code is first written constant
      refactoring is good, as it improves the design based on lessons learnt about
      implementation. When code reuse starts, interfaces become hardened and
      cannot be refactored. Of course, the implementation can be, but some
      flexibility is lost. What do others think?

      Nick Fortescue





      ________________________________________________________________________
      ________________________________________________________________________

      Message: 2
      Date: Mon, 30 Apr 2001 09:20:32 -0000
      From: davechaplin@...
      Subject: Re: Reuseability

      Mattias,

      In my view Design Patterns are essential knowledge for anyone doing
      OO projects. They are the language of communicating part of the
      design. I consider them analogous to building roads - you use a bunch
      of designs (roundabouts, junctions, tunnels etc). If you have to keep
      explaining what a tunnel is to other programmers it takes too long
      and you can suffer from poor communication.

      In terms of re-use of code: If you are using a tiered architecure,
      then you should be able to re-use any data Providers at the back end,
      together with any utility libraries. In terms of re-using code from
      the domain model - I would not bother, other than ripping it out and
      pasting it into newly designed code. I've found this useful for
      serilaisation/deserialisation code.

      In my view, the best form of re-use is a common architectural
      framework. e.g. One I swear by is: Presentation, Process, Business
      Model, Commands, Providers, Data sources.

      Good luck....!

      Dave Chaplin

      --- In extremeprogramming@y..., mattias@s... wrote:
      > Hi!
      >
      > I am currently working with a project which is working out how
      > reusability and design patterns would increase the value of the
      > defense software projects in Sweden.
      >
      > Of course I will try to trick them into adopting some agile
      software
      > development process (not straight XP because of the size of the
      > projects and the addiction to a certain amount of paperwork), but
      the
      > thing is how to do that when the very main subject on the study is
      > REUSE.
      >
      > One tip is to reuse the tests.
      >
      > How have you done? Are there never one single reused code-line in
      > your different XP projects?
      >
      > Can the refactorings lead to objects that are easier to reuse?
      > Or can you reuse a few objects and refactor them into a new design
      > (reuse of tests included here)?
      >
      > Any suggestions are welcome
      > /Mattias
      >
      > P.S. I have been following the discussion on design patterns, and
      it
      > was very helpful. Lots of good thoughts. Thanks! D.S.



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 3
      Date: Mon, 30 Apr 2001 09:51:30 -0000
      From: kentbeck@...
      Subject: Re: XP/R - Extreme Programming/Remote

      --- In extremeprogramming@y..., "Chris McKinstry" <kcmckinstry@h...>
      wrote:
      > I don't believe there is any such thing as creep. As soon as I hear
      > someone who claims to get XP say creep, I know they don't.

      Please don't hand me straight lines like this. Please. Jeffries, you
      owe me one.

      Kent



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 4
      Date: Mon, 30 Apr 2001 06:27:30 -0400
      From: Dan Palanza <dan@...>
      Subject: Re: Re: Reuseability

      At 09:20 AM 4/30/01 -0000, Dave Chaplin wrote:

      >In my view Design Patterns are essential knowledge for anyone doing
      >OO projects. They are the language of communicating part of the
      >design. I consider them analogous to building roads - you use a bunch
      >of designs (roundabouts, junctions, tunnels etc). If you have to keep
      >explaining what a tunnel is to other programmers it takes too long
      >and you can suffer from poor communication.

      You have described precisely how Alexander first approached pattern study.
      That type of focus on things led him, and his group, to write the book, "A
      Pattern Language." Then he found a deeper pattern image. e.g., Every
      roundabout has certain categories of concern:
      (1) each pattern has a body made up of 'resources';
      (2) resources get worked-generated--into a 'product';
      (3) construction, design, and use describe a 'history';
      (4) history's best interests are decided in rules of 'policy'.

      Clearly, 'junction' and 'tunnel' and indeed all 'patterns' have these same
      four categories of concern that a roundabout has. All patterns, in that
      patterns are both a thing and an idea, are implemented as resources made
      into product by ideas. Ideas that move resources to product generate a real
      history worth recording, to enable reuse. What's more, history will
      influence policy that will decide how each pattern is to be constructed and
      used.

      Universals offer a different way to look at pattern discovery.

      >In my view, the best form of re-use is a common architectural
      >framework. e.g. One I swear by is: Presentation, Process, Business
      >Model, Commands, Providers, Data sources.

      I think you are headed in the same direction--toward universal
      patterns--with the categories you have found useful to differentiate, and
      follow, above.

      In bookkeeping the 'architectural framework' that best served reuse became
      a small number of universal categories. The framework that these categories
      created then became the test framework for the application of accounting.
      IOW bookkeeping is the test for accounting.

      My guess is that when the XP dust settles there will emerge a universal
      test framework for the application of computer programs.

      Dan




      ________________________________________________________________________
      ________________________________________________________________________

      Message: 5
      Date: Mon, 30 Apr 2001 07:19:41 -0400
      From: Ron Jeffries <ronjeffries@...>
      Subject: Re: XP/R - Extreme Programming/Remote

      Responding to kentbeck@... (09:51 AM 4/30/2001 +0000):
      >--- In extremeprogramming@y..., "Chris McKinstry" <kcmckinstry@h...>
      >wrote:
      > > I don't believe there is any such thing as creep. As soon as I hear
      > > someone who claims to get XP say creep, I know they don't.
      >
      >Please don't hand me straight lines like this. Please. Jeffries, you
      >owe me one.

      I owe you many, Kent, but not for this one AFAICS.

      R




      ________________________________________________________________________
      ________________________________________________________________________

      Message: 6
      Date: Mon, 30 Apr 2001 06:25:03 -0500 (CDT)
      From: Ralph Johnson <johnson@...>
      Subject: Re: Reusability

      The customer has said that reusability is a requirement, so
      I suppose by the rules of XP, it is OK to assume it is needed.
      But that fact is that a lot of people say they want reusability
      when it is not cost-effective.

      Here is how to do it. Come up with a set of applications that
      would be built with your reusable software. This will be your
      "user stories". It is good if they span the range of applications
      that will eventually be built, but usually you will miss some.
      Then build applications, one at a time. Separate the software
      into the part that is shared by the applications, and the part
      that is not. Each new application will require refactoring the
      shared part, which will require refactoring the non-shared part.
      This is just part of the cost of developing reusable software.
      After you have made three or four applications on one code base,
      you'll discover that the amount of changes to the reusable part
      goes way down. The software is now in fact reusable. Build
      some more applications, and you can now do them in parallel.

      Note that refactoring the reused code will force you to refactor
      the old applications. The alternative is to have several versions
      of the reused code, and that is worse, because you do not know for
      sure whether your new version "runs the old tests", i.e. is really
      compatible with the requirements of the old applications. Keep
      one version of the code as long as possible, and just keep refactoring
      your old applications. Once you send the code to other groups, you
      won't have the luxury of only supporting one version.

      -Ralph Johnson



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 7
      Date: Mon, 30 Apr 2001 13:40:43 +0200 (MEST)
      From: Astrid Schroeder <schroeda@...-muenchen.de>
      Subject: Studies on XP searched


      Hello!

      I'm a student of Computer Science at Munich University of Technology,
      Germany. I'm doing my master's thesis about Extreme Programming (XP).

      For this reason I'm searching for studies on XP and its techniques. I
      already found a study on Pair Programming by Laurie Williams, but I'm
      searching for more, so if perhaps anyone knows a study or has an idea
      where to find one, I'd appreciate if you could tell me.

      Furthermore, as a focus of my thesis is to find out how XP is applied in
      fact and how it can be improved, I would be glad, if you do an X Project
      or you are an XP consultant, if you could fill in the little questionnaire
      found at

      http://www4.informatik.tu-muenchen.de/~rumpe/questionnaire.txt
      respectively
      http://www4.informatik.tu-muenchen.de/~rumpe/questionnaire.doc

      and email it to schroeda@... as soon as possible.

      Thanks!

      Astrid





      ________________________________________________________________________
      ________________________________________________________________________

      Message: 8
      Date: Mon, 30 Apr 2001 06:42:49 -0700
      From: Kenneth Tyler <kentyler@...>
      Subject: Re: Reuseability

      ...
      >My attitude at the moment is that when code is first written constant
      >refactoring is good, as it improves the design based on lessons learnt
      about
      >implementation. When code reuse starts, interfaces become hardened and
      >cannot be refactored. Of course, the implementation can be, but some
      >flexibility is lost. What do others think?
      Nick,
      Have you looked at generative programming. If you have parallel or
      similar code it is a candidate for being generated, then you refactor the
      generator and all the generated code is updated in all the applications that
      use it. It means defining some rules about how the generated code will work
      that the other code in the applications have to live by, but it gives you
      reuse...

      Kenneth Tyler www.tinyxp.com berkeley, ca



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 9
      Date: Mon, 30 Apr 2001 10:01:28 -0400
      From: "Moss, D" <dmoss@...>
      Subject:




      ________________________________________________________________________
      ________________________________________________________________________

      Message: 10
      Date: Mon, 30 Apr 2001 15:12:42 +0100
      From: "Nick Fortescue" <nick@...>
      Subject: Re: Reuseability

      From: "Kenneth Tyler" <kentyler@...>
      > ...
      > >My attitude at the moment is that when code is first written constant
      > >refactoring is good, as it improves the design based on lessons learnt
      > about
      > >implementation. When code reuse starts, interfaces become hardened and
      > >cannot be refactored. Of course, the implementation can be, but some
      > >flexibility is lost. What do others think?
      > Nick,
      > Have you looked at generative programming. If you have parallel or
      > similar code it is a candidate for being generated, then you refactor the
      > generator and all the generated code is updated in all the applications
      that
      > use it. It means defining some rules about how the generated code will
      work
      > that the other code in the applications have to live by, but it gives you
      > reuse...

      I think this affects a different issue (as an aside, I do use code
      generators in my current project).
      Maybe an example would help. One common redesign, which might be done
      through a sequence of refactorings is in io. Suppose you want to be able to
      write a certain type of data (with a representative class) as XML and read
      it in again. One design is to have the reading and writing done by the
      class. One design is to have the reading and writing done by a separate
      object. There are strengths and weaknesses to both designs, and in different
      situations different designs will be the "simplest thing possible".

      While coding orignally you may switch between the designs, possible more
      than once, especially if this is quick to do through refactoring. Once you
      release the code to other users and it is being reused it is very hard to
      change this design as it would require the users to change all their code.
      Of course, in this case you put it behind the interface, but you still
      always have to support the old methods in your interface.
      Reuse has lost you a bit of flexibility. This is shown well by Martin's
      paper

      http://www.objectmentor.com/publications/oodmetrc.pdf

      The most interesting thing I found it showed indirectly is that the more
      people reuse code, the more reusable it is. This is because the more people
      who use it, the more static it is, so the more people can depend on it not
      changing from underneath them.

      Nick Fortescue





      ________________________________________________________________________
      ________________________________________________________________________

      Message: 11
      Date: Mon, 30 Apr 2001 11:33:54 -0400
      From: Andrew Hunt <andy@...>
      Subject: Re: all OO programmers should learn design patterns

      azami@... reports:

      >We also had someone for whom a computer would never fail. We could
      >consistently generate a program crash until she came and stood near
      >the computer - then it would work. If someone brought us a file that
      >caused the software to crash when trying to print, we'd have her come
      >stand by the computer so the print would go through. I don't know why
      >it worked.

      Magnetic personality, I guess. You don't want these people standing
      around while you're unit testing!!

      >Incidentally, I told my (now) wife about the printer dance while she
      >was an undergrad (oh, around '95). She also had success using the
      >"printer dance" with her department's finnicky printer. She did have
      >some explaining to do, however, when a fellow student walked in on
      >her! :-)

      Forget XP, what we need is a good totem pole...

      :-)

      /\ndy


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 12
      Date: Mon, 30 Apr 2001 15:38:58 -0000
      From: lindstrom@...
      Subject: Re: Refactorings Paper

      I had to go to http://www.cs.utexas.edu/users/schwartz/ first and
      then click on Publications



      --- In extremeprogramming@y..., "Glen B. Alleman" <galleman@n...>
      wrote:
      > For those of you who may be like me and want to see some more
      deatils about
      > a topic. Either to put to use or to improve understanding there is
      a nice
      > paper on Refactoring in a real world environment at
      > http://www.cs.utexas.edu/users/schwartz/pub.htm.
      > This paper is a case study of how refactoring has been studied in
      the
      > SEMATEC project, which is a very large scale CORBA based system for
      the
      > semiconductor industry.
      >
      >
      > Glen Alleman
      > Niwot Ridge Consulting
      >
      > "You can never judge the future by the past" - Edmund Burke
      >
      >
      > [Non-text portions of this message have been removed]



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 13
      Date: Mon, 30 Apr 2001 11:55:45 -0400
      From: Angus Mezick <amezick@...>
      Subject: Developing a secure link

      Right now I am designing a security protocol for transmitting financial
      transactions over the internet. This is something where the design of the
      item really has to be thought through and closely examined for holes. I
      was wondering how something like this could be developed using XP and where
      in the process it would fit? Somewhere in the stories? Or when the
      developers create tasks? Or generated using spikes? If we get this wrong,
      we get in BIG trouble. (Your accounts numbers out there for all to see.)
      --Angus
      P.S. I had no idea that a question about MVC could go so far :)


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 14
      Date: Date header was inserted by mta7.pltn13.pbi.net
      From: Kevin Smith <sent@...>
      Subject: Re: Reusability

      Ralph Johnson wrote:
      >The customer has said that reusability is a requirement, so
      >I suppose by the rules of XP, it is OK to assume it is needed.
      >But that fact is that a lot of people say they want reusability
      >when it is not cost-effective.

      Excellent point. I've been pondering this myself
      recently, and it seems that reuse is a tool, not
      a goal in itself. I'm really thinking of reuse
      across projects here, not within a project which
      would relate to OAOO and DRY.

      Generally, I think the perceived benefits of
      reuse across projects are:
      - Lower costs
      - Easier maintenance
      - Higher reliability

      Within the XP model, I suspect that cross-project
      reuse actually costs more and makes maintenance
      more difficult, while adding nothing to
      reliability.

      I guess I'm also not talking about creating
      generic tools that can be reused. And I'm not
      talking about libraries that naturally evolve out
      of several related projects. I'm talking about
      actual production code that is shared in just two
      or three projects.

      Am I way off base, here?

      Kevin


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 15
      Date: Mon, 30 Apr 2001 12:09:40 -0400
      From: Ron Jeffries <ronjeffries@...>
      Subject: Re: Developing a secure link

      Responding to Angus Mezick (11:55 AM 4/30/2001 -0400):
      >Right now I am designing a security protocol for transmitting financial
      >transactions over the internet. This is something where the design of the
      >item really has to be thought through and closely examined for holes. I
      >was wondering how something like this could be developed using XP and where
      >in the process it would fit? Somewhere in the stories? Or when the
      >developers create tasks? Or generated using spikes? If we get this wrong,
      >we get in BIG trouble. (Your accounts numbers out there for all to see.)

      I don't know much about the problem or solution. Why isn't it sufficient to
      do a strong encryption on each message? How do secure sites already do
      this? Isn't it a well-known technology (even though I personally don't know
      it)?

      Regards,



      Ronald E Jeffries
      http://www.XProgramming.com
      http://www.objectmentor.com


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 16
      Date: Mon, 30 Apr 2001 12:25:41 -0400
      From: Angus Mezick <amezick@...>
      Subject: Re: Developing a secure link

      Let me simplify my question: How do you use XP to Design something whose
      design HAS to be bullet proof? Using a security protocol as an example.

      BTW:
      We are thinking about a system that uses public key encryption to pass a
      symmetric encryption algorithm's key. (symmetric is faster than public
      key) This symmetric key is generated for each client/server
      communication. Client is Java. Server is legacy C++.
      --Angus

      Ron Jeffries wrote:
      >
      > Responding to Angus Mezick (11:55 AM 4/30/2001 -0400):
      > >Right now I am designing a security protocol for transmitting financial
      > >transactions over the internet. This is something where the design of
      the
      > >item really has to be thought through and closely examined for holes. I
      > >was wondering how something like this could be developed using XP and
      where
      > >in the process it would fit? Somewhere in the stories? Or when the
      > >developers create tasks? Or generated using spikes? If we get this
      wrong,
      > >we get in BIG trouble. (Your accounts numbers out there for all to see.)
      >
      > I don't know much about the problem or solution. Why isn't it sufficient
      to
      > do a strong encryption on each message? How do secure sites already do
      > this? Isn't it a well-known technology (even though I personally don't
      know
      > it)?
      >
      > Regards,
      >
      > Ronald E Jeffries


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 17
      Date: Mon, 30 Apr 2001 12:36:05 -0400
      From: Ron Jeffries <ronjeffries@...>
      Subject: Re:

      Responding to Angus Mezick (12:25 PM 4/30/2001 -0400):
      >Let me simplify my question: How do you use XP to Design something whose
      >design HAS to be bullet proof? Using a security protocol as an example.

      Not to seem opaque, but what part of incremental development and merciless
      refactoring and relentless testing seems inadequate to your needs?



      Ronald E Jeffries
      http://www.XProgramming.com
      http://www.objectmentor.com


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 18
      Date: Mon, 30 Apr 2001 12:37:29 -0400
      From: "Paul Gunn" <pgunn@...>
      Subject: Re: Developing a secure link

      > BTW:
      > We are thinking about a system that uses public key encryption to pass a
      > symmetric encryption algorithm's key. (symmetric is faster than public
      > key) This symmetric key is generated for each client/server
      > communication. Client is Java. Server is legacy C++.
      > --Angus

      I seem to recall from college that this approach is one commonly used by SSL
      and possibly other protocols - ie. after initial negotiation, the encryption
      is handled symetrically. Unless you have other unique requirements, you may
      be able to find an existing protocol that meets your needs.

      (Agreeing that the underlying question is one interesting of discussion)

      Paul Gunn



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 19
      Date: Mon, 30 Apr 2001 12:54:10 -0400
      From: Angus Mezick <amezick@...>
      Subject: Re: Re:

      Those practice, to me, will generate working/bug free/pretty code that will
      do exactly what is needed. Security protocols, in my mind, need to be
      picked apart and dissected by many people because there will be someone out
      there trying to get through them to the juicy data within. To me,
      incremental development does not seem as reassuring as having a group of
      people (~4-6 smart ones) think about ways in and out of this protocol. I
      agree that the solution itself will be a story, broken up into tasks, pair
      programmed, incrementally developed, unit/feature tested, and mercilessly
      refactored. I also agree that my particular problem has been solved
      before, but where would XP solve it for a yet to be determined problem?
      --Angus

      Ron Jeffries wrote:
      >
      > Responding to Angus Mezick (12:25 PM 4/30/2001 -0400):
      > >Let me simplify my question: How do you use XP to Design something whose
      > >design HAS to be bullet proof? Using a security protocol as an example.
      >
      > Not to seem opaque, but what part of incremental development and merciless
      > refactoring and relentless testing seems inadequate to your needs?
      >
      > Ronald E Jeffries


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 20
      Date: Mon, 30 Apr 2001 16:54:52 -0000
      From: azami@...
      Subject: Re: Reuseability

      --- In extremeprogramming@y..., "Nick Fortescue" <nick@o...> wrote:
      > My attitude at the moment is that when code is first written
      constant
      > refactoring is good, as it improves the design based on lessons
      learnt about
      > implementation. When code reuse starts, interfaces become hardened
      and
      > cannot be refactored. Of course, the implementation can be, but some
      > flexibility is lost. What do others think?

      I think that is precisely the difference between a "public" interface
      and a "published" interface.

      -Matthew
      azami@...




      ________________________________________________________________________
      ________________________________________________________________________

      Message: 21
      Date: Mon, 30 Apr 2001 17:27:21 -0000
      From: "Lee" <lvbis@...>
      Subject: Re: Studies on XP searched

      --- In extremeprogramming@y..., Astrid Schroeder <schroeda@i...>
      wrote:
      > I'm a student of Computer Science at Munich University of
      Technology, Germany. I'm doing my master's thesis about Extreme
      Programming (XP). For this reason I'm searching for studies on XP
      and its techniques. I already found a study on Pair Programming by
      Laurie Williams, but I'm searching for more, so if perhaps anyone
      knows a study or has an idea where to find one, I'd appreciate if you
      could tell me.

      === Trying contacting Linda Werner, a member of AAUW.ORG. According
      to the University of Carolina - Santa Cruz web site, "...work in
      progress under the leadership of Linda Werner, a lecturer in
      computer science, who received a National Science Foundation
      grant to explore the use of pair programming with students in
      introductory-level computer science courses." If you send me an
      off-line email, I'll send you her direct email address.

      Lee in Las Vegas



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 22
      Date: Mon, 30 Apr 2001 17:38:46 -0000
      From: "Lee" <lvbis@...>
      Subject: Re: Studies on XP searched

      --- In extremeprogramming@y..., Astrid Schroeder <schroeda@i...>
      wrote:
      > ... but I'm searching for more, so if perhaps anyone knows a study
      or has an idea where to find one, I'd appreciate if you could tell me.

      === According to the National Science Foundation, "This CISE
      Information Technology Workforce (ITW) proposal requests funds to
      examine the effects of pair-programming on female students'
      perceived self-confidence and interest in computer science as
      well as their retention and achievement in these courses.
      Approximately, 400 students enrolled in introductory computer
      science courses will complete a series of programming
      assignments in pairs (same and mixed gender pairs) or i
      independently. It is hypothesized that women who program in pairs
      will produce better programs in terms of functionality and
      readability, report greater confidence in their solutions, enjoy
      programming more, and have higher retention rates in computer
      science and related areas than women who program independently.
      This project has the potential to provide valuable insights into
      the retention of women in computer science."

      Check it out by going to the NSF home page and searching for:
      AWARD 0089989. It's title is: ITW: Retaining Women in Computer
      Science Programs: The Impact of Pair-Programming.

      Lee in Las Vegas



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 23
      Date: Mon, 30 Apr 2001 18:58:15 +0100
      From: "Nick Fortescue" <nick@...>
      Subject: Re: Re: secure programming

      From: "Ron Jeffries" <ronjeffries@...>
      > Responding to Angus Mezick (12:25 PM 4/30/2001 -0400):
      > >Let me simplify my question: How do you use XP to Design something whose
      > >design HAS to be bullet proof? Using a security protocol as an example.
      >
      > Not to seem opaque, but what part of incremental development and merciless
      > refactoring and relentless testing seems inadequate to your needs?

      My understanding of the question is the question of adequate testing. XP
      says test everything that can go wrong. In normal programming, what can go
      wrong is in forgetfulness of the programmer, and slightly more for user
      input, but it usually is not malicious. For security protocols what can go
      wrong is everything. Funny spoofed packets, the lot. This is why you cannot
      test everything that can go wrong, because this set is infinite, so testing
      is not enough in these circumstances.

      A good discussion of these issues can be found in the secure programming
      list archive. Go to www.securityfocus.com and click on lists,secprog on the
      sidebar. See the FAQ and read the archive.

      It's a good question that Angus asks. I can think of four part answers, but
      no whole ones.
      1) Make sure that someone on the team knows about protocol security issues
      and make sure he pairs the protocol parts and especially the tests. The XP
      pairing should lead to a better result than normal where the advice is to
      get the Expert to inspect your code.
      2) Make the protocol part of the story. Designing your own protocols is one
      of the most common security mistakes. Make the story "Use the public
      standard protocol wibblespoo.311". As well as the benefit of all that expert
      checking and inspection it is much easier to write tests for conformance to
      a published protocing, ol design than an abstract "secure".
      3) Segregate the secure code into it's own area, and make the tests in this
      area far more extensive than normal. You might want to use monte-carlo
      testing (with fixed seed for repeatability) even if you don't normally do
      this.
      4) Use a protocol security testing tool as part of your tests, such as FDR2
      http://www.formal.demon.co.uk/FDR2.html

      Any more?

      Nick Fortescue




      ________________________________________________________________________
      ________________________________________________________________________

      Message: 24
      Date: Mon, 30 Apr 2001 13:15:17 -0500
      From: wecaputo@...
      Subject: Re: Re:


      Angus:
      >Those practice, to me, will generate working/bug free/pretty code that
      will
      >do exactly what is needed.

      And part of what is needed is bulletproof code so...

      >To me, incremental development does not seem as reassuring as having a
      group of
      >people (~4-6 smart ones) think about ways in and out of this protocol.

      Why not have these 4-6 smart ones helping to define tests?

      How long do they get to think their way through the protocol?
      3 weeks? 6 months?

      What if they spent that time improving an implementation of the initial
      best guess?

      Which one would be better? Why?

      Best,
      Bill



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 25
      Date: Fri, 27 Apr 2001 19:52:42 GMT
      From: rmartin@...
      Subject: How to use design patterns.

      There has recently been a conjecture placed on the extreme programming
      mail group that Design Patterns are harmful. The complaint is that
      designers try to force patterns into a design rather than trying to
      determine the best structure for the design.

      I am sympathetic to this view. However I don't think design patterns
      are harmful. Indeed, I consider lack of knowledge of design patterns
      a mark of irresponsibility in a software professional. Design
      Patterns represent an invaluable body of knowledge that describes how
      past engineers have solved common problems. This cannot help but be
      of aid to future engineers facing those problems.

      Still, patterns are not a panacea. They do not solve all design
      problems. Nor do they represent a tool, method, or recipe for solving
      design problems. Rather they are simply descriptions of what has
      worked in a few situations in the past.

      How should designers employ design patterns? In my opinion they
      should not *try* to employ them at all. Rather designers need to
      become so intimately familiar with design patterns that they simply
      know when a given pattern fits into their design or not.

      This notion of "fit" is a tricky one. It is easy to face a design
      problem and leap to a pattern that solves it. But does that pattern
      provide a solution that is appropriate to the context? Or might there
      be a simpler solution?

      Design patterns should not be used in lieu of finding the best design.
      A designer might consider a particular pattern to help solve a
      problem; but should not assume that the pattern is the best solution.
      A pattern is not "best" simply because it is a pattern.

      One can view the choice of a pattern as a hypothesis: "I hypothesize
      that the observer pattern is a good solution to this problem." A good
      designer will then set about to choose a set of experiments that will
      verify this hypothesis. Those experiments are likely to be tiny
      stepwise implementations if test cases that, bit by bit, implement the
      problem to be solved. At any time during this implementation, the
      pattern should be viewed only as a vague direction, not as the law.
      And should the experiments show that the pattern is not optimal, the
      pattern should be abandoned.

      I have an article that demonstrates this technique appearing in my
      column in an upcoming Java Report.


      Robert C. Martin | "Uncle Bob" | Software Consultants
      Object Mentor Inc. | rmartin@... | We'll help you get
      PO Box 5757 | Tel: (800) 338-6716 | your projects done.
      565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
      Suite 135 | | www.XProgramming.com
      Vernon Hills, IL, | Training and Mentoring | www.junit.org
      60061 | OO, XP, Java, C++, Python|

      "One of the great commandments of science is:
      'Mistrust arguments from authority.'" -- Carl Sagan


      ________________________________________________________________________
      ________________________________________________________________________



      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Bretz, Matt
      ... From: extremeprogramming@yahoogroups.com [mailto:extremeprogramming@yahoogroups.com] Sent: Monday, April 30, 2001 5:24 PM To:
      Message 2 of 20 , May 1, 2001
      • 0 Attachment
        -----Original Message-----
        From: extremeprogramming@yahoogroups.com
        [mailto:extremeprogramming@yahoogroups.com]
        Sent: Monday, April 30, 2001 5:24 PM
        To: extremeprogramming@yahoogroups.com
        Subject: [XP] Digest Number 1065


        To Post a message, send it to: extremeprogramming@...

        To Unsubscribe, send a blank message to:
        extremeprogramming-unsubscribe@...

        Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods.
        Early registration discounts EXTENDED until May 1, 2001. www.xpuniverse.com
        for details and registration.
        ------------------------------------------------------------------------

        There are 25 messages in this issue.

        Topics in this digest:

        1. Re: Re:
        From: Ron Jeffries <ronjeffries@...>
        2. RE: Re: Refactorings Paper
        From: "Arrizza, John" <john.arrizza@...>
        3. RE: Re: secure programming
        From: "Gareth Reeves" <reevesg@...>
        4. Re: secure programming
        From: azami@...
        5. Re: Re: secure programming
        From: "Nick Fortescue" <nick@...>
        6. Re: How to use design patterns.
        From: "Lee" <lvbis@...>
        7. Re: Refactorings Paper
        From: "Lee" <lvbis@...>
        8. Re: Re: secure programming
        From: "Nick Fortescue" <nick@...>
        9. YAGNI
        From: Brian Christopher Robinson <brian@...>
        10. Re: YAGNI
        From: Phlip <pplumlee@...>
        11. Re: secure programming
        From: azami@...
        12. Re: Developing a secure link
        From: Art Taylor <reeses@...>
        13. Re: YAGNI
        From: azami@...
        14. Re: YAGNI
        From: Phil Goodwin <phil.goodwin@...>
        15. Re: YAGNI
        From: Ron Jeffries <ronjeffries@...>
        16. (OTUG) How to use design patterns.
        From: rmartin@...
        17. Re: YAGNI
        From: "Brian C. Robinson" <brian.c.robinson@...>
        18. FW: (OTUG) XP and Rocket Guidance
        From: "Ken Boyer" <ken@...>
        19. Re: FW: (OTUG) XP and Rocket Guidance
        From: "Lee" <lvbis@...>
        20. Re: YAGNI
        From: Ron Jeffries <ronjeffries@...>
        21. Re: YAGNI
        From: Phil Goodwin <phil.goodwin@...>
        22. Re: Developing a secure link
        From: jbrewer@...
        23. Re: Developing a secure link
        From: jbrewer@...
        24. (OTUG) How to use design patterns.
        From: rmartin@...
        25. (OTUG) How to use design patterns.
        From: rmartin@...


        ________________________________________________________________________
        ________________________________________________________________________

        Message: 1
        Date: Mon, 30 Apr 2001 14:26:48 -0400
        From: Ron Jeffries <ronjeffries@...>
        Subject: Re: Re:

        Responding to Angus Mezick (12:54 PM 4/30/2001 -0400):
        >Those practice, to me, will generate working/bug free/pretty code that will
        >do exactly what is needed.

        Defense rests.

        >Security protocols, in my mind, need to be
        >picked apart and dissected by many people because there will be someone out
        >there trying to get through them to the juicy data within.

        If you believe that, you should do design sessions and/or code reviews.

        >To me,
        >incremental development does not seem as reassuring as having a group of
        >people (~4-6 smart ones) think about ways in and out of this protocol. I
        >agree that the solution itself will be a story, broken up into tasks, pair
        >programmed, incrementally developed, unit/feature tested, and mercilessly
        >refactored.

        If you need this reassurance this way, then you should get it this way.

        >I also agree that my particular problem has been solved
        >before, but where would XP solve it for a yet to be determined problem?

        I hate to admit it, but I cannot say in advance how I'd solve an as yet
        undetermined problem.

        Regards,


        Ronald E Jeffries
        http://www.XProgramming.com
        http://www.objectmentor.com


        ________________________________________________________________________
        ________________________________________________________________________

        Message: 2
        Date: Mon, 30 Apr 2001 14:28:35 -0400
        From: "Arrizza, John" <john.arrizza@...>
        Subject: RE: Re: Refactorings Paper


        > -----Original Message-----
        > From: lindstrom@... [mailto:lindstrom@...]
        > I had to go to http://www.cs.utexas.edu/users/schwartz/ first and
        > then click on Publications

        I tried this as well. I get a [x] instead of the doc. (I do have adobe
        acrobat installed). I also tried ftp and then acrobat, still no luck. anyone
        else with this problem?

        John


        ________________________________________________________________________
        ________________________________________________________________________

        Message: 3
        Date: Mon, 30 Apr 2001 13:43:53 -0500
        From: "Gareth Reeves" <reevesg@...>
        Subject: RE: Re: secure programming

        > In normal programming, what can go
        > wrong is in forgetfulness of the programmer, and slightly more for user
        > input, but it usually is not malicious. For security protocols what can go
        > wrong is everything. Funny spoofed packets, the lot. This is why
        > you cannot
        > test everything that can go wrong, because this set is infinite,
        > so testing
        > is not enough in these circumstances.

        Interesting, what other techniques would you use to ensure your design was
        good in the face of infinite possibilities?

        Gareth



        ________________________________________________________________________
        ________________________________________________________________________

        Message: 4
        Date: Mon, 30 Apr 2001 18:50:04 -0000
        From: azami@...
        Subject: Re: secure programming

        --- In extremeprogramming@y..., "Gareth Reeves" <reevesg@p...> wrote:
        > Interesting, what other techniques would you use to ensure your
        design was
        > good in the face of infinite possibilities?

        I would open the design and code to inspection by anyone. Security
        that relies on secrets in the code is not security. I would
        absolutely not be satisfied by 4-6 experts reviewing and blessing the
        security design.

        It is possible that in the realm of security, provable correctness may
        have lots of value. You would still want to hammer it with tests.
        You want the tests to show that the thing you are doing is the thing
        you proved correct, and you want tests that do weird corruptions and
        such. Any time anyone comes up with a new possible breach, write the
        test for it. In keeping with "openness", allow anyone in the world to
        submit new test cases for you. Run massive monte carlo tests.

        Regarding the general issue, what do you do if code NEEDS to be
        BULLETPROOF? IMO, testing is even more important, and your tests need
        to hurl bullets at the code. In general, if XP practices lead to more
        reliable code, why wouldn't an XP project more closely approach the
        bulletproof ideal than would a more traditional project?




        ________________________________________________________________________
        ________________________________________________________________________

        Message: 5
        Date: Mon, 30 Apr 2001 20:02:11 +0100
        From: "Nick Fortescue" <nick@...>
        Subject: Re: Re: secure programming


        > > In normal programming, what can go
        > > wrong is in forgetfulness of the programmer, and slightly more for user
        > > input, but it usually is not malicious. For security protocols what can
        go
        > > wrong is everything. Funny spoofed packets, the lot. This is why
        > > you cannot
        > > test everything that can go wrong, because this set is infinite,
        > > so testing
        > > is not enough in these circumstances.
        >
        > Interesting, what other techniques would you use to ensure your design was
        > good in the face of infinite possibilities?

        As I said this is something that is discussed a lot on the secure
        programming list, so
        I'm reluctant to go too much into it here, as I won't get it all right,
        those who have
        seen it all before will be bored, and I won't say it as well. However a
        brief summary of some well known techniques:

        1) Formal (mathematical) methods allow you prove a limited amount given a
        limited set of assumptions. There is a lot of writing about this. As I was
        trained in this at Oxford, I'd biasedly suggest you look there
        www.comlab.ox.ac.uk, but there are a lot of books on the subject.
        2) In security you tend to make the default "disallowed", and only do
        something if it is explicitly allowed. This prevents you having to think
        about the infinite disallowed cases. However, you can't easliy test you are
        doing this.
        3) Limit scope. If you make the "secure" portion of your code as restricted
        as possible, then the smallest amount of your code is infinitely hard to
        test.
        4) Security professionals know several patterns of well known attacks, eg
        buffer overflow, the zero case, etc.) A lot of attacks are just variations
        on these common mistakes. So there are an infinite number of Word Macro
        viruses, but most can be tested for by checking you prompt before running
        Macros.Code inspections by such a professional or professionals can point
        out flaws, and advice from them may help produce a wide coverage of test
        cases with a small number of tests.
        5) Making code open-source can help get as many eyes on the code as
        possible, making it more likely flaws will be found.

        How all of these integrate into XP is something I really don't know. Does
        anyone have any thoughts on this?

        Nick Fortescue







        ________________________________________________________________________
        ________________________________________________________________________

        Message: 6
        Date: Mon, 30 Apr 2001 18:53:21 -0000
        From: "Lee" <lvbis@...>
        Subject: Re: How to use design patterns.

        --- In extremeprogramming@y..., rmartin@o... wrote:
        > One can view the choice of a pattern as a hypothesis: "I
        hypothesize that the observer pattern is a good solution to this
        problem." A good designer will then set about to choose a set of
        experiments that will verify this hypothesis. Those experiments are
        likely to be tiny stepwise implementations if test cases that, bit by
        bit, implement the problem to be solved. At any time during this
        implementation, the pattern should be viewed only as a vague
        direction, not as the law. And should the experiments show that the
        pattern is not optimal, the pattern should be abandoned.

        === Robert, you make some great observations here regarding the use
        of design patterns. Let me add one item for thought to the
        process -- design patterns help keep a team focused.

        I agree that patterns should *always* be reviewed. Flaws in
        the process can usually be identified by the team and corrected
        by the paired programmers. Once the corrections are made, a
        new design can be generated to properly track these changes. I
        know the XP community as a whole have an natural dislike for
        designs as they do not contribute to code generation. However,
        I find them a useful tool for helping keep everyone on track and
        focused on the process at hand.

        Lee in Las Vegas



        ________________________________________________________________________
        ________________________________________________________________________

        Message: 7
        Date: Mon, 30 Apr 2001 18:56:28 -0000
        From: "Lee" <lvbis@...>
        Subject: Re: Refactorings Paper

        --- In extremeprogramming@y..., "Arrizza, John" <john.arrizza@m...>
        wrote:
        > I tried this as well. I get a [x] instead of the doc. (I do have
        adobe acrobat installed). I also tried ftp and then acrobat, still no
        luck. anyone else with this problem?
        >
        > John

        === Here it is: ftp://ftp.cs.utexas.edu/pub/predator/ase2000.pdf

        Lee in Las Vegas



        ________________________________________________________________________
        ________________________________________________________________________

        Message: 8
        Date: Mon, 30 Apr 2001 20:09:31 +0100
        From: "Nick Fortescue" <nick@...>
        Subject: Re: Re: secure programming


        From: <azami@...>
        > Regarding the general issue, what do you do if code NEEDS to be
        > BULLETPROOF? IMO, testing is even more important, and your tests need
        > to hurl bullets at the code. In general, if XP practices lead to more
        > reliable code, why wouldn't an XP project more closely approach the
        > bulletproof ideal than would a more traditional project?

        I agreed with everything you wrote that I have cut out. I think the risk is
        that XP projects tend not to have design up front, and detailed design
        documents. If you are working on a security protocol and constantly
        refactoring with no code ownership it might be very difficult to write tests
        which prevent flaws being introduced. For example, a good general security
        rule is "Never write user input controlled strings to printf etc as you
        might get format string vulnerabilities". But it is hard to write test cases
        which prevent two novices pairing together introducing such bugs into your
        code.
        In this case XP might not be the best way of working. On the other hand,
        writing test cases first and constant pairing is fantastic for security.

        Nick Fortescue






        ________________________________________________________________________
        ________________________________________________________________________

        Message: 9
        Date: Mon, 30 Apr 2001 15:05:46 -0500
        From: Brian Christopher Robinson <brian@...>
        Subject: YAGNI

        A question about YAGNI. Let's say I'm creating a class for my program. I
        have two possible ways of doing it that AFAICT are equally good in terms of
        the story I'm working on now. However, I know that one way will be better
        for some future story I'm not working on yet. Is it wrong to work with
        that future knowledge?



        ________________________________________________________________________
        ________________________________________________________________________

        Message: 10
        Date: Mon, 30 Apr 2001 12:14:12 -0700
        From: Phlip <pplumlee@...>
        Subject: Re: YAGNI

        Proclaimed Brian Christopher Robinson from the mountaintops:

        > A question about YAGNI. Let's say I'm creating a class for my program.
        > I have two possible ways of doing it that AFAICT are equally good in
        > terms of the story I'm working on now. However, I know that one way
        > will be better for some future story I'm not working on yet. Is it
        > wrong to work with that future knowledge?

        YAGNI does not mean you pretend you know nothing about the project except
        the past and current UserStories.

        It means you don't waste gobs of time investing in speculative code. No
        gold-plating, or adding "flexibility". The correct way to add flexibility
        is to let further UserStories flex the design!

        If you say the two ways are equally "good", let's take that to mean they
        will be around the same line count. Or maybe even the predictive version
        is 5% longer. Go ahead and code it. This is not the same as the Bad Old
        Days, when folks would hole up and code, hand over fist, entire packages
        entirely on speculation.

        http://c2.com/cgi/wiki?JobSecurity

        --
        Phlip phlip_cpp@...
        ============== http://phlip.webjump.com ==============
        This signature was automatically generated with
        Signify v1.06. For this and other cool products,
        check out http://www.debian.org/


        ________________________________________________________________________
        ________________________________________________________________________

        Message: 11
        Date: Mon, 30 Apr 2001 19:29:05 -0000
        From: azami@...
        Subject: Re: secure programming

        --- In extremeprogramming@y..., "Nick Fortescue" <nick@o...> wrote:
        > rule is "Never write user input controlled strings to printf etc as
        you
        > might get format string vulnerabilities". But it is hard to write
        test cases
        > which prevent two novices pairing together introducing such bugs
        into your
        > code.

        Good point. I'd suggest making rules like that explicit in a coding
        standard, and occasionally brainstorming for ways to test it. (How
        about a string object with a "user input" attribute? Ensure that
        string objects can only be printed through their own methods? I'm not
        actually trying to solve it, but I do think a team that needs it
        should occasionally try.)

        Although not normally required for XP, I'd definitely subject the
        security-critical work of a pair of novices to review.

        In fact, I'd probably subject all security-critical work to review. I
        suppose this is effectively the purpose of opening the source.


        -Matthew
        azami@...




        ________________________________________________________________________
        ________________________________________________________________________

        Message: 12
        Date: Mon, 30 Apr 2001 12:30:15 -0700
        From: Art Taylor <reeses@...>
        Subject: Re: Developing a secure link

        Angus Mezick (amezick@...) wrote:
        > Right now I am designing a security protocol for transmitting financial
        > transactions over the internet. This is something where the design of the
        > item really has to be thought through and closely examined for holes. I
        > was wondering how something like this could be developed using XP and
        where
        > in the process it would fit? Somewhere in the stories? Or when the
        > developers create tasks? Or generated using spikes? If we get this
        wrong,
        > we get in BIG trouble. (Your accounts numbers out there for all to see.)
        > --Angus

        We have done something very similar to this, using XP, in the past
        month or so. Someone else in this thread mentioned the exact thing we
        did.

        We needed to build a remote API that didn't depend on external
        libraries, yet was reasonably secure. We decided to use asymmetric
        keys for the client->server communication, and include a symmetric key
        with each client request. The response would be encrypted with this
        symmetric key, saving us the hassle of storing client public keys on
        the server. The resource advantage of the symmetric key algorithms
        was a nice little side benefit.

        The way we approached this in an incremental fashion, was to build a
        client that would communicate via unencrypted http, to a server API
        that understood unencrypted messages via http. At first, it was
        just,"Hi Mom!"

        The User Stories read "Client can connect to server via sockets",
        "Client can send a message to the server", "Client message can be
        xml-formatted", "Client request will be encrypted", etc.

        Over the next week (pair programming is amazing for the speed at which
        you move using it), we added the xml messaging parsers and generators
        (special-case serialisers, since we didn't want to use outside
        libraries), the encryption/decryption and compression filters, and a
        large number of API call handler classes.

        Each of these features was tidily composed with test drivers, and
        integrated within a day, which is why we structured them in that way.
        We used accepted standard encryption protocols, but we used them from
        the Crypto++ library, and repackaged that open-source library to
        include only the protocols we needed, saving a lot of space.

        You know that you're not going to get your financial application
        hacked up in a day, but you can pick little chunks of it that can be
        done in a day, to grow a tiny,"Look, this much of it works!" seed into
        the full application. We used a string-of-filters metaphor and built
        it into our application, which made that stepwise development easy and
        not frustrating. You might need to find a different metaphor, but
        you'll know when you come up with it, because you won't be worried any
        more.

        As for specific protocol implementations, I would really recommend
        using something standard, rather than developing your own. Take
        something right out of Schneier, because it has been reviewed by
        people who do that for a living.

        If you want more details about how we solved our particular problem,
        feel free to email me.

        -a.


        [Non-text portions of this message have been removed]



        ________________________________________________________________________
        ________________________________________________________________________

        Message: 13
        Date: Mon, 30 Apr 2001 19:36:58 -0000
        From: azami@...
        Subject: Re: YAGNI

        --- In extremeprogramming@y..., Brian Christopher Robinson
        <brian@d...> wrote:
        > A question about YAGNI. Let's say I'm creating a class for my
        program. I
        > have two possible ways of doing it that AFAICT are equally good in
        terms of
        > the story I'm working on now. However, I know that one way will be
        better
        > for some future story I'm not working on yet. Is it wrong to work
        with
        > that future knowledge?

        Suppose you solve the problem with the informed design (the way that's
        better for the future story). Then, that story gets dropped. How do
        you feel about the state of the code? Is it as simple as it can
        possibly be?

        Now, suppose you solve the problem the other way. The future story
        becomes current, and you begin working on it by refactoring from the
        design you used to the design you considered. How much does this
        hurt?

        -Matthew
        azami@...




        ________________________________________________________________________
        ________________________________________________________________________

        Message: 14
        Date: Mon, 30 Apr 2001 12:36:58 -0700
        From: Phil Goodwin <phil.goodwin@...>
        Subject: Re: YAGNI

        At 03:05 PM 4/30/01 -0500, Brian Christopher Robinson wrote:
        >A question about YAGNI. Let's say I'm creating a class for my program. I
        >have two possible ways of doing it that AFAICT are equally good in terms of

        >the story I'm working on now. However, I know that one way will be better
        >for some future story I'm not working on yet. Is it wrong to work with
        >that future knowledge?

        The impulse to kill two birds with one stone is a distraction that is best
        avoided. If you are thinking about two different stories while you are
        writing code then you aren't writing the best code you can. Think about one
        story at a time and let the tests force you to complicate your thinking if
        and when that becomes necessary.


        ----------------------------------------------------------------------------
        --------------------------------
        Phil Goodwin, Java Software, Sun Microsystems, 408-517-6951, or x66951

        "If everything you try works, you aren't trying hard enough." -- Gordon
        Moore



        ________________________________________________________________________
        ________________________________________________________________________

        Message: 15
        Date: Mon, 30 Apr 2001 15:41:36 -0400
        From: Ron Jeffries <ronjeffries@...>
        Subject: Re: YAGNI

        Responding to Brian Christopher Robinson (03:05 PM 4/30/2001 -0500):
        >A question about YAGNI. Let's say I'm creating a class for my program. I
        >have two possible ways of doing it that AFAICT are equally good in terms of
        >the story I'm working on now. However, I know that one way will be better
        >for some future story I'm not working on yet. Is it wrong to work with
        >that future knowledge?

        Is one of them simpler than the other? I always go with the simplest. But I
        try not to do things that would obviously work.

        Can you think of a specific example?



        Ronald E Jeffries
        http://www.XProgramming.com
        http://www.objectmentor.com


        ________________________________________________________________________
        ________________________________________________________________________

        Message: 16
        Date: Fri, 27 Apr 2001 19:52:42 GMT
        From: rmartin@...
        Subject: (OTUG) How to use design patterns.

        There has recently been a conjecture placed on the extreme programming
        mail group that Design Patterns are harmful. The complaint is that
        designers try to force patterns into a design rather than trying to
        determine the best structure for the design.

        I am sympathetic to this view. However I don't think design patterns
        are harmful. Indeed, I consider lack of knowledge of design patterns
        a mark of irresponsibility in a software professional. Design
        Patterns represent an invaluable body of knowledge that describes how
        past engineers have solved common problems. This cannot help but be
        of aid to future engineers facing those problems.

        Still, patterns are not a panacea. They do not solve all design
        problems. Nor do they represent a tool, method, or recipe for solving
        design problems. Rather they are simply descriptions of what has
        worked in a few situations in the past.

        How should designers employ design patterns? In my opinion they
        should not *try* to employ them at all. Rather designers need to
        become so intimately familiar with design patterns that they simply
        know when a given pattern fits into their design or not.

        This notion of "fit" is a tricky one. It is easy to face a design
        problem and leap to a pattern that solves it. But does that pattern
        provide a solution that is appropriate to the context? Or might there
        be a simpler solution?

        Design patterns should not be used in lieu of finding the best design.
        A designer might consider a particular pattern to help solve a
        problem; but should not assume that the pattern is the best solution.
        A pattern is not "best" simply because it is a pattern.

        One can view the choice of a pattern as a hypothesis: "I hypothesize
        that the observer pattern is a good solution to this problem." A good
        designer will then set about to choose a set of experiments that will
        verify this hypothesis. Those experiments are likely to be tiny
        stepwise implementations if test cases that, bit by bit, implement the
        problem to be solved. At any time during this implementation, the
        pattern should be viewed only as a vague direction, not as the law.
        And should the experiments show that the pattern is not optimal, the
        pattern should be abandoned.

        I have an article that demonstrates this technique appearing in my
        column in an upcoming Java Report.


        Robert C. Martin | "Uncle Bob" | Software Consultants
        Object Mentor Inc. | rmartin@... | We'll help you get
        PO Box 5757 | Tel: (800) 338-6716 | your projects done.
        565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
        Suite 135 | | www.XProgramming.com
        Vernon Hills, IL, | Training and Mentoring | www.junit.org
        60061 | OO, XP, Java, C++, Python|

        "One of the great commandments of science is:
        'Mistrust arguments from authority.'" -- Carl Sagan

        -----------------------------------------------------------------
        To unsubscribe from OTUG, send an email to majordomo@...
        with the word 'unsubscribe' in the body of the message.


        ________________________________________________________________________
        ________________________________________________________________________

        Message: 17
        Date: Mon, 30 Apr 2001 15:58:11 -0500
        From: "Brian C. Robinson" <brian.c.robinson@...>
        Subject: Re: YAGNI

        At 02:41 PM 4/30/01, you wrote:
        >Can you think of a specific example?

        Actually this is something that has almost but not quite come up a couple
        of times in our project. Basically, I will be thinking about something and
        one of the options I am considering looks like it might be useful in the
        future but then when I think about it some more I realize that it probably
        won't. But it did lead me to the hypothetical situation I originally
        described.



        ________________________________________________________________________
        ________________________________________________________________________

        Message: 18
        Date: Mon, 30 Apr 2001 16:08:07 -0400
        From: "Ken Boyer" <ken@...>
        Subject: FW: (OTUG) XP and Rocket Guidance

        ----- Original Message -----
        From: "Ron Jeffries" <RonJeffries@...>
        Sent: Friday, April 27, 2001 3:36 PM
        > Responding to Ken Boyer (10:03 AM 4/27/2001 -0400):
        > >OK. Now we're getting somewhere. We can boil this down to a few
        questions:
        > >1. Where is the boundary of XP? I.e. how much can you modify it before it
        > >becomes ~XP?
        >
        > However ... every time I coach any team, there's something different about

        > their situation. There are tweaks always, and sometimes important changes.

        > I do my best to advise them, and don't worry too much about whether
        they're
        > doing XP ... the important thing is to do well.

        I'm trying to get to these tweaks. What are the axes along which the tweaks
        are made, or is that why people like you are hired? :-)

        > >What I'm trying to do, probably like many people, is discern the
        continuum
        > >that
        > >ties the Agile processes together, and that goes from them "up" a little
        to
        > >processes which could be used for, say, rocket guidance. If we try to
        work
        > >through this, we're dispelling the confusing messages from DeMarco and
        > >Beck, which don't really tell us anything about evolving or enhancing XP.
        >
        > Mostly we don't know that much, and [I think] that what we do know is that

        > one shouldn't just set off to enhance XP without contact with the pure
        quill.

        Well, OK, but one might want to add a few carefully selected areas to
        enhance specific attributes, such as peer review and requirements
        management.

        > I keep saying this, and the evidence is that I won't stop: I've done a lot

        > of software over a lot of years. The XP practices, I believe, put you in
        > touch with your code, your project, and your colleagues, in a way that
        I've
        > not reproducibly experienced in the past. It seems to have all the good
        > aspects of the "garage shop", without the bad ones.

        OK, I'm not doubting that, at least not anymore. As someone steeped in
        the realm of life-critical software, I am viewing XP with one of the most
        critical gazes of anyone. I see little specks which make it, in its out-of-
        the-box form, somewhat lacking in direct applicability to my realm. We've
        touched on these things, and I'm trying to formulate an enhancement
        which may remain nothing but an intellectual exercise for me. Or, I may
        ask you to review it for publication in a journal...

        Kenneth W. Boyer Jr. <><
        ASQ Certified Software Quality Engineer
        VASCOR, Inc. - Pittsburgh, PA USA




        ________________________________________________________________________
        ________________________________________________________________________

        Message: 19
        Date: Mon, 30 Apr 2001 20:16:40 -0000
        From: "Lee" <lvbis@...>
        Subject: Re: FW: (OTUG) XP and Rocket Guidance

        --- In extremeprogramming@y..., "Ken Boyer" <ken@v...> wrote:
        > OK, I'm not doubting that, at least not anymore. As someone steeped
        in the realm of life-critical software, I am viewing XP with one of
        the most critical gazes of anyone. I see little specks which make it,
        in its out-of-the-box form, somewhat lacking in direct applicability
        to my realm. We've touched on these things, and I'm trying to
        formulate an enhancement which may remain nothing but an intellectual
        exercise for me. Or, I may ask you to review it for publication in a
        journal...
        >
        > Kenneth W. Boyer Jr. <><
        > ASQ Certified Software Quality Engineer
        > VASCOR, Inc. - Pittsburgh, PA USA

        === As discussed in previous threads, XP is one of the most agile
        methodologies in use today. However, it is not without its slight
        flaws and minor shortcomings. I'm working to bring the majority
        of XP processes online in our company, with a few corrections or
        internal enhancements that will allow it meet governmental needs.
        All in all, I've been very impressed with it as a development
        methodology.

        Lee in Las Vegas



        ________________________________________________________________________
        ________________________________________________________________________

        Message: 20
        Date: Mon, 30 Apr 2001 16:28:10 -0400
        From: Ron Jeffries <ronjeffries@...>
        Subject: Re: YAGNI

        Responding to Ron Jeffries (03:41 PM 4/30/2001 -0400):
        >But I
        >try not to do things that would obviously work.

        Actually I try not to do things that would obviously NOT work ... ;->



        Ronald E Jeffries
        http://www.XProgramming.com
        http://www.objectmentor.com


        ________________________________________________________________________
        ________________________________________________________________________

        Message: 21
        Date: Mon, 30 Apr 2001 13:29:58 -0700
        From: Phil Goodwin <phil.goodwin@...>
        Subject: Re: YAGNI

        At 03:05 PM 4/30/01 -0500, Brian Christopher Robinson wrote:
        >A question about YAGNI. Let's say I'm creating a class for my program. I
        >have two possible ways of doing it that AFAICT are equally good in terms of

        >the story I'm working on now. However, I know that one way will be better
        >for some future story I'm not working on yet. Is it wrong to work with
        >that future knowledge?

        I think that it depends on how you use it. If it's deepening your
        understanding of your current story then it's good. If it's distracting you
        with considerations that aren't pertinent to your current story then it's
        not so good.

        Trying to figure out which is which is a distraction itself.

        When I'm working on a particular story I try to make sure that I focus on
        that story. If I find myself thinking about another story I check to see
        whether my thoughts are getting clearer and more focused or whether I'm
        starting to get distracted (this comes out as either worry or fascination).
        If I'm distracted I write down my thought on a card and re-focus on the
        current story. If I'm getting clarity I go with it.

        The original question assumes that you are working on a pretty course
        grained level of design: which class to use. If you are thinking about what
        method to write next the problem pretty much goes away for a while. When it
        comes back it will be in the form of how to refactor the methods into
        classes that make more sense. At that point the other story you were
        worrying about probably won't enter into the picture. Unless of course
        you've started to implement it by the time this refactoring wants to happen.
        Thinking this way makes the original question seem less relevant: if you
        aren't planning your classes ahead of implementing them it doesn't make
        sense to ponder about how that planning should be done.

        ----------------------------------------------------------------------------
        --------------------------------
        Phil Goodwin, Java Software, Sun Microsystems, 408-517-6951, or x66951

        "If everything you try works, you aren't trying hard enough." -- Gordon
        Moore



        ________________________________________________________________________
        ________________________________________________________________________

        Message: 22
        Date: Mon, 30 Apr 2001 21:03:13 -0000
        From: jbrewer@...
        Subject: Re: Developing a secure link

        --- In extremeprogramming@y..., Angus Mezick <amezick@e...> wrote:
        > Let me simplify my question: How do you use XP to Design something
        whose
        > design HAS to be bullet proof? Using a security protocol as an
        example.

        Get a security expert. XP is not a replacement for domain expertise.

        Nothing is bullet proof, given a big enough bullet. Security experts
        measure the security of a system in terms of estimated effort
        required to compromise it, usually measured in dollars. Your
        customer would probably prefer a system that cost millions rather
        than dozens of dollars to breach, but that's really his call to make.

        Security is about the whole system, not just the software. All the
        formal software verification in the world isn't going to help you if
        your sysadmin chooses "aardvark" as the root password. Or if a
        criminal decides the easiest way in is to bribe your $5/hour security
        guard.

        The good news is that computer criminals are lazy, and you're one of
        literally millions of targets. To avoid attacks, you just have to be
        a little less convenient than the other targets. That's not too
        hard, since there are a lot of unpatched IIS servers out there.

        > We are thinking about a system that uses public key encryption to
        pass a
        > symmetric encryption algorithm's key. (symmetric is faster than
        public
        > key) This symmetric key is generated for each client/server
        > communication. Client is Java. Server is legacy C++.

        Unless you have a _very_ good reason not to, by all means use an
        off-the-shelf protocol (like SSL), and an off-the-shelf library.
        It's been tested more than your home-grown stuff ever could be, and if
        it's ever breached, you'll likely hear about it in the news.

        John Brewer
        Jera Design

        XP FAQ: http://www.jera.com/techinfo/xpfaq.html



        ________________________________________________________________________
        ________________________________________________________________________

        Message: 23
        Date: Mon, 30 Apr 2001 21:14:14 -0000
        From: jbrewer@...
        Subject: Re: Developing a secure link

        --- In extremeprogramming@y..., Angus Mezick <amezick@e...> wrote:
        > Let me simplify my question: How do you use XP to Design something
        whose
        > design HAS to be bullet proof? Using a security protocol as an
        example.

        Hire a security expert. XP is not an replacement for required
        domain expertise.

        Nothing is bulletproof, given a large enough bullet. Security
        experts typically evaluate the security of a system in terms of how
        much effort (usually expressed in dollars) it would take to breach
        it. Your customer would probably prefer a system that would costs
        millions, rather than dozens, of dollars to breach, but that's
        largely his decision.

        Remember that security is about the whole system, not just the
        program. All the formal verification methods and design reviews in
        the world aren't going to help you if your sysadmin makes the root
        password "aardvark". Or if a criminal decides that the cheapest way
        in is to bribe your $5/hour security guard.

        The good news is that computer criminals are lazy. Your security
        doesn't have to be perfect, just good enough so that a criminal gets
        discouraged and looks for an easier target.

        > BTW:
        > We are thinking about a system that uses public key encryption to
        pass a
        > symmetric encryption algorithm's key. (symmetric is faster than
        public
        > key) This symmetric key is generated for each client/server
        > communication. Client is Java. Server is legacy C++.

        Unless you have a _very_ good reason not to, you should use an
        existing protocol (like SSL), and a well-known existing
        implementation (like RSA's). That way, you take advantage of a huge
        existing body of testing and verification, and you'll likely hear
        about it in the news if there's been a breech.

        John Brewer
        Jera Design

        XP FAQ: http://www.jera.com/xpfaq.html



        ________________________________________________________________________
        ________________________________________________________________________

        Message: 24
        Date: Fri, 27 Apr 2001 19:52:42 GMT
        From: rmartin@...
        Subject: (OTUG) How to use design patterns.

        There has recently been a conjecture placed on the extreme programming
        mail group that Design Patterns are harmful. The complaint is that
        designers try to force patterns into a design rather than trying to
        determine the best structure for the design.

        I am sympathetic to this view. However I don't think design patterns
        are harmful. Indeed, I consider lack of knowledge of design patterns
        a mark of irresponsibility in a software professional. Design
        Patterns represent an invaluable body of knowledge that describes how
        past engineers have solved common problems. This cannot help but be
        of aid to future engineers facing those problems.

        Still, patterns are not a panacea. They do not solve all design
        problems. Nor do they represent a tool, method, or recipe for solving
        design problems. Rather they are simply descriptions of what has
        worked in a few situations in the past.

        How should designers employ design patterns? In my opinion they
        should not *try* to employ them at all. Rather designers need to
        become so intimately familiar with design patterns that they simply
        know when a given pattern fits into their design or not.

        This notion of "fit" is a tricky one. It is easy to face a design
        problem and leap to a pattern that solves it. But does that pattern
        provide a solution that is appropriate to the context? Or might there
        be a simpler solution?

        Design patterns should not be used in lieu of finding the best design.
        A designer might consider a particular pattern to help solve a
        problem; but should not assume that the pattern is the best solution.
        A pattern is not "best" simply because it is a pattern.

        One can view the choice of a pattern as a hypothesis: "I hypothesize
        that the observer pattern is a good solution to this problem." A good
        designer will then set about to choose a set of experiments that will
        verify this hypothesis. Those experiments are likely to be tiny
        stepwise implementations if test cases that, bit by bit, implement the
        problem to be solved. At any time during this implementation, the
        pattern should be viewed only as a vague direction, not as the law.
        And should the experiments show that the pattern is not optimal, the
        pattern should be abandoned.

        I have an article that demonstrates this technique appearing in my
        column in an upcoming Java Report.


        Robert C. Martin | "Uncle Bob" | Software Consultants
        Object Mentor Inc. | rmartin@... | We'll help you get
        PO Box 5757 | Tel: (800) 338-6716 | your projects done.
        565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
        Suite 135 | | www.XProgramming.com
        Vernon Hills, IL, | Training and Mentoring | www.junit.org
        60061 | OO, XP, Java, C++, Python|

        "One of the great commandments of science is:
        'Mistrust arguments from authority.'" -- Carl Sagan

        -----------------------------------------------------------------
        To unsubscribe from OTUG, send an email to majordomo@...
        with the word 'unsubscribe' in the body of the message.


        ________________________________________________________________________
        ________________________________________________________________________

        Message: 25
        Date: Fri, 27 Apr 2001 19:52:42 GMT
        From: rmartin@...
        Subject: (OTUG) How to use design patterns.

        There has recently been a conjecture placed on the extreme programming
        mail group that Design Patterns are harmful. The complaint is that
        designers try to force patterns into a design rather than trying to
        determine the best structure for the design.

        I am sympathetic to this view. However I don't think design patterns
        are harmful. Indeed, I consider lack of knowledge of design patterns
        a mark of irresponsibility in a software professional. Design
        Patterns represent an invaluable body of knowledge that describes how
        past engineers have solved common problems. This cannot help but be
        of aid to future engineers facing those problems.

        Still, patterns are not a panacea. They do not solve all design
        problems. Nor do they represent a tool, method, or recipe for solving
        design problems. Rather they are simply descriptions of what has
        worked in a few situations in the past.

        How should designers employ design patterns? In my opinion they
        should not *try* to employ them at all. Rather designers need to
        become so intimately familiar with design patterns that they simply
        know when a given pattern fits into their design or not.

        This notion of "fit" is a tricky one. It is easy to face a design
        problem and leap to a pattern that solves it. But does that pattern
        provide a solution that is appropriate to the context? Or might there
        be a simpler solution?

        Design patterns should not be used in lieu of finding the best design.
        A designer might consider a particular pattern to help solve a
        problem; but should not assume that the pattern is the best solution.
        A pattern is not "best" simply because it is a pattern.

        One can view the choice of a pattern as a hypothesis: "I hypothesize
        that the observer pattern is a good solution to this problem." A good
        designer will then set about to choose a set of experiments that will
        verify this hypothesis. Those experiments are likely to be tiny
        stepwise implementations if test cases that, bit by bit, implement the
        problem to be solved. At any time during this implementation, the
        pattern should be viewed only as a vague direction, not as the law.
        And should the experiments show that the pattern is not optimal, the
        pattern should be abandoned.

        I have an article that demonstrates this technique appearing in my
        column in an upcoming Java Report.


        Robert C. Martin | "Uncle Bob" | Software Consultants
        Object Mentor Inc. | rmartin@... | We'll help you get
        PO Box 5757 | Tel: (800) 338-6716 | your projects done.
        565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
        Suite 135 | | www.XProgramming.com
        Vernon Hills, IL, | Training and Mentoring | www.junit.org
        60061 | OO, XP, Java, C++, Python|

        "One of the great commandments of science is:
        'Mistrust arguments from authority.'" -- Carl Sagan

        -----------------------------------------------------------------
        To unsubscribe from OTUG, send an email to majordomo@...
        with the word 'unsubscribe' in the body of the message.

        -----------------------------------------------------------------
        To unsubscribe from OTUG, send an email to majordomo@...
        with the word 'unsubscribe' in the body of the message.


        ________________________________________________________________________
        ________________________________________________________________________



        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • Fabio Armani
        unsubscribe [Non-text portions of this message have been removed]
        Message 3 of 20 , May 4, 2001
        • 0 Attachment
          unsubscribe


          [Non-text portions of this message have been removed]
        • Karen Chetrit
          extremeprogramming-unsubscribe@eGroups.com
          Message 4 of 20 , Jul 27, 2001
          • 0 Attachment
          • Molitor, Stephen
            unsubscribe
            Message 5 of 20 , Jul 28, 2001
            • 0 Attachment
              unsubscribe
            • Jim.Hyslop
              ... Welcome to the Hotel California... You can check out any time you like, but you can never leave. :-) Seriously, though, Åsa, I found that it can take a
              Message 6 of 20 , Dec 12, 2001
              • 0 Attachment
                Lee Armstrong <lee_armstrong39@...> wrote:
                > --- Åsa Berggren <asa.berggren@...> wrote:
                > > Hi,
                > >
                > > I have tried several times to unsubscribe to this
                > > mailling list
                >
                > Why would you want to do that? I don't think we
                > should tell you...
                Welcome to the Hotel California... You can check out any time you like, but
                you can never leave. :-)

                Seriously, though, Åsa, I found that it can take a while for the yahoogroups
                server to process an unsubscribe request after the verification. If you're
                still having problems, try emailing the list owners at
                extremeprogramming-owner@yahoogroups.com

                --
                Jim
              • Rob Myers
                Jim, ... Thank you! You may have just given me a metaphor for our latest XP project. (It certainly beats the vacuum cleaner metaphor, which simply sucked.)
                Message 7 of 20 , Dec 12, 2001
                • 0 Attachment
                  Jim,

                  > Welcome to the Hotel California... You can check out any time you
                  > like, but
                  > you can never leave. :-)

                  Thank you! You may have just given me a metaphor for our latest XP project.

                  (It certainly beats the vacuum cleaner metaphor, which simply sucked.)

                  Rob

                  Rob Myers
                  XP Coach/Programmer
                  Mindful Software
                  www.mindfulsoftware.com
                • Chris Young-InteractiveTV
                  This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have
                  Message 8 of 20 , Apr 14, 2002
                  • 0 Attachment
                    This e-mail (and any attachments) is confidential and may contain personal
                    views which are not the views of the BBC unless specifically stated.
                    If you have received it in error, please delete it from your system, do not use,
                    copy or disclose the information in any way nor act in reliance on it and notify
                    the sender immediately. Please note that the BBC monitors e-mails sent
                    or received. Further communication will signify your consent to this.
                  • Arun Kaushik
                    unsubscribe __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
                    Message 9 of 20 , May 22, 2002
                    • 0 Attachment
                      unsubscribe

                      __________________________________________________
                      Do You Yahoo!?
                      LAUNCH - Your Yahoo! Music Experience
                      http://launch.yahoo.com
                    • Arun Kaushik
                      unsubscribe __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
                      Message 10 of 20 , May 22, 2002
                      • 0 Attachment
                        unsubscribe

                        __________________________________________________
                        Do You Yahoo!?
                        LAUNCH - Your Yahoo! Music Experience
                        http://launch.yahoo.com
                      • Molitor, Stephen
                        unsubscribe
                        Message 11 of 20 , Oct 2, 2002
                        • 0 Attachment
                          unsubscribe
                        • Rodel P. Hipolito
                          Rodel P. Hipolito Ecommsite Solutions, Inc. A: 30th Floor IBM Plaza Eastwood City Cyberpark E. Rodriguez Jr. Avenue Libis, Quezon City T: +632-4219406 F:
                          Message 12 of 20 , Oct 30, 2003
                          • 0 Attachment
                            Rodel P. Hipolito
                            Ecommsite Solutions, Inc.
                            A: 30th Floor IBM Plaza
                            Eastwood City Cyberpark
                            E. Rodriguez Jr. Avenue
                            Libis, Quezon City
                            T: +632-4219406
                            F: +632-9122788 loc 110
                            W: http://www.ecommsite.com
                            http://www.sysads.org
                            E: rhipolito@...
                            M: +639209060595
                          • Rodel P. Hipolito
                            Rodel P. Hipolito Ecommsite Solutions, Inc. A: 30th Floor IBM Plaza Eastwood City Cyberpark E. Rodriguez Jr. Avenue Libis, Quezon City T: +632-4219406 F:
                            Message 13 of 20 , Nov 6, 2003
                            • 0 Attachment
                              Rodel P. Hipolito
                              Ecommsite Solutions, Inc.
                              A: 30th Floor IBM Plaza
                              Eastwood City Cyberpark
                              E. Rodriguez Jr. Avenue
                              Libis, Quezon City
                              T: +632-4219406
                              F: +632-9122788 loc 110
                              W: http://www.ecommsite.com
                              http://www.sysads.org
                              E: rhipolito@...
                              M: +639209060595
                            • Ivan Tomek
                              unsubscribe
                              Message 14 of 20 , Feb 22 10:10 AM
                              • 0 Attachment
                                unsubscribe
                              • Harald Svensson
                                Hello, I want to unsubscribe to this mail group, I have tried to send a blank message to the suggested mail address but to no use. What must I do to stop
                                Message 15 of 20 , Jan 13, 2006
                                • 0 Attachment
                                  Hello, I want to unsubscribe to this mail group, I have tried to send a
                                  blank message to the suggested mail address but to no use.

                                  What must I do to stop recieve all these mail from the extreme programming
                                  group!?



                                  Best regards
                                  Harald
                                • Ian Collins
                                  ... Go to the url and unsubscribe there. Ian
                                  Message 16 of 20 , Jan 13, 2006
                                  • 0 Attachment
                                    Harald Svensson wrote:

                                    >Hello, I want to unsubscribe to this mail group, I have tried to send a
                                    >blank message to the suggested mail address but to no use.
                                    >
                                    >What must I do to stop recieve all these mail from the extreme programming
                                    >group!?
                                    >
                                    >
                                    >
                                    >
                                    Go to the url and unsubscribe there.

                                    Ian
                                  • Ron Jeffries
                                    ... I ve removed you. Good luck! Ron Jeffries www.XProgramming.com The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
                                    Message 17 of 20 , Jan 13, 2006
                                    • 0 Attachment
                                      On Friday, January 13, 2006, at 7:36:54 PM, Harald Svensson wrote:

                                      > Hello, I want to unsubscribe to this mail group, I have tried to send a
                                      > blank message to the suggested mail address but to no use.

                                      > What must I do to stop recieve all these mail from the extreme programming
                                      > group!?

                                      I've removed you. Good luck!

                                      Ron Jeffries
                                      www.XProgramming.com
                                      The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
                                    Your message has been successfully submitted and would be delivered to recipients shortly.