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

Success of XP over Formal Methods

Expand Messages
  • Matt Heusser
    ... Yes, but the formal methods people were trying to do The Right Thing (TRT) whereas extreme programming takes the track of Worse Is Better. Here is a
    Message 1 of 11 , Apr 30, 2007
    • 0 Attachment
      Paolo Bizzarri Asked:

      >Now, it has been an interesting question (at least for me) why formal
      >methods have got so little success, whereas XP have got so much more
      >success. Both fields were practiced by smart people, interested in
      >producing better code.
      >

      Yes, but the formal methods people were trying to do "The Right Thing" (TRT)
      whereas extreme programming takes the track of "Worse Is Better."

      Here is a brief primer on worse is better:

      http://www.jwz.org/doc/worse-is-better.html


      ----> I quite seriously believe that worse-is-better should be considered
      part of the Software Development Foundation Literature, right up there with
      No Silver Bullets, Learn to Program in Ten Years, Why Does Software Cost So
      Much, Cargo-Cult Software Engineering, and PeopleWare. If you haven't read
      it, I urge you to consider it.

      ----> Hey! I've got a podcast up on xndev.blogspot.com (12 minutes) that I
      think you might enjoy. Or search in iTunes for "Creative Chaos"

      Regards,

      --
      Matthew Heusser,
      Blog: http://xndev.blogspot.com


      [Non-text portions of this message have been removed]
    • Steven Gordon
      I do not understand the terminology worse is better . I find just good enough to be a more accurate term. Is just good enough not controversial enough?
      Message 2 of 11 , Apr 30, 2007
      • 0 Attachment
        I do not understand the terminology "worse is better". I find "just good
        enough" to be a more accurate term. Is "just good enough" not controversial
        enough?

        Steve

        On 4/30/07, Matt Heusser <matt.heusser@...> wrote:
        >
        > Paolo Bizzarri Asked:
        >
        > >Now, it has been an interesting question (at least for me) why formal
        > >methods have got so little success, whereas XP have got so much more
        > >success. Both fields were practiced by smart people, interested in
        > >producing better code.
        > >
        >
        > Yes, but the formal methods people were trying to do "The Right Thing"
        > (TRT)
        > whereas extreme programming takes the track of "Worse Is Better."
        >
        > Here is a brief primer on worse is better:
        >
        > http://www.jwz.org/doc/worse-is-better.html
        >
        > ----> I quite seriously believe that worse-is-better should be considered
        > part of the Software Development Foundation Literature, right up there
        > with
        > No Silver Bullets, Learn to Program in Ten Years, Why Does Software Cost
        > So
        > Much, Cargo-Cult Software Engineering, and PeopleWare. If you haven't read
        > it, I urge you to consider it.
        >
        > ----> Hey! I've got a podcast up on xndev.blogspot.com (12 minutes) that I
        > think you might enjoy. Or search in iTunes for "Creative Chaos"
        >
        > Regards,
        >
        > --
        > Matthew Heusser,
        > Blog: http://xndev.blogspot.com
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >


        [Non-text portions of this message have been removed]
      • Micron Engineering
        ... this is not a good example. A good sw engineeris is always a good sw engineer, its ability doesn t depend by the tools and approaches he uses. Surely a
        Message 3 of 11 , Apr 30, 2007
        • 0 Attachment
          Matt Heusser ha scritto:
          >
          > Paolo Bizzarri Asked:
          >
          > >Now, it has been an interesting question (at least for me) why formal
          > >methods have got so little success, whereas XP have got so much more
          > >success. Both fields were practiced by smart people, interested in
          > >producing better code.
          > >
          >
          > Yes, but the formal methods people were trying to do "The Right Thing"
          > (TRT)
          > whereas extreme programming takes the track of "Worse Is Better."
          >
          > Here is a brief primer on worse is better:
          >
          > http://www.jwz.org/doc/worse-is-better.html
          > <http://www.jwz.org/doc/worse-is-better.html>
          >












          this is not a good example. A good sw engineeris is always a good sw
          engineer, its ability doesn't depend by
          the tools and approaches he uses. Surely a different tool or a different
          approach may increase productivity and
          quality but can't change a bad sw engineer to a good sw engineer. A bad
          sw engineer that uses XP methods
          will do errors also. Your example points to a type of engineer with low
          analisys capabilities, this is not the common unix sw developer
          scenario. XP is just a new set of tool in the sw engineers toolbox.
          Personally in my projects I find useful some XP ideas and also I find
          useful other ideas coming from PSP/TSP, "Rapid Development" and others.
          I don't think that there is one better way to develop software projects;
          probably the best
          for me, for you and for others is different because also our
          applications are different. May be that a mix of XP and
          traditional development cycle models customized for a particular range
          of applications could be a more reasonable
          approach. Of course the problem is still the same: customize a process
          tailored with personal (in a group sense) requirements.
          Just to do an example: if a customer ask to have a cost and time
          estimate to develop her last mega-super-software ip phone,
          giving you 200 pages of requirements, your goal is to give that answer;
          sure you cant try to convince her to use an XP approach but if her goal
          is to obtain the estimation from you it is difficult that he will accept
          an XP approach without having a preliminary estimation. Also your
          interest may be to produce an accurate estimation without investing a
          lot of hours of work (normally you loose this time if you will not do
          the job) and your potential customer may give the same requirements to 5
          different companies to have 5 estimations from which he will choose the
          winning one. So in this situation XP strategies may help you? I think no
          (please tell me if I am wrong).
          >
          >
          > ----> I quite seriously believe that worse-is-better should be considered
          > part of the Software Development Foundation Literature, right up there
          > with
          > No Silver Bullets, Learn to Program in Ten Years, Why Does Software
          > Cost So
          > Much, Cargo-Cult Software Engineering, and PeopleWare. If you haven't read
          > it, I urge you to consider it.
          >
          > ----> Hey! I've got a podcast up on xndev.blogspot.com (12 minutes) that I
          > think you might enjoy. Or search in iTunes for "Creative Chaos"
          >
          > Regards,
          >
          > --
          > Matthew Heusser,
          > Blog: http://xndev.blogspot.com <http://xndev.blogspot.com>
          >
          > [Non-text portions of this message have been removed]
          >
          >
          > ------------------------------------------------------------------------
          >
          > No virus found in this incoming message.
          > Checked by AVG Free Edition.
          > Version: 7.5.467 / Virus Database: 269.6.2/780 - Release Date: 29/04/2007 06.30
          >



          [Non-text portions of this message have been removed]
        • David Carlton
          ... XP doesn t feel very Worse Is Better to me: Worse Is Better doesn t have rules taken to extremes the way XP does, I think. From the link ...
          Message 4 of 11 , Apr 30, 2007
          • 0 Attachment
            On Mon, 30 Apr 2007 08:22:00 -0400, "Matt Heusser" <matt.heusser@...> said:

            > Yes, but the formal methods people were trying to do "The Right
            > Thing" (TRT) whereas extreme programming takes the track of "Worse
            > Is Better."

            XP doesn't feel very "Worse Is Better" to me: Worse Is Better doesn't
            have rules taken to extremes the way XP does, I think. From the link
            you gave:

            > http://www.jwz.org/doc/worse-is-better.html

            Simplicitly: both sides like it, with Right Thing liking it on the
            interface and Worse Is Better liking it on the implementation. In the
            Worse Is Better example they give, of a system call returning an error
            code where the user has to check and retry, XP would see this as code
            duplication, would refactor the check and retry into the
            implementation, and the result would look like the Right Thing
            version. (Of course, there aren't the same interface/implementation
            boundaries as in XP, so that whole distinction is a bit off.)

            Correctness: "Incorrectness is simply not allowed" seems to me to be
            reasonably consistent with XP, but it's on the Right Thing side.

            Consistency: at first I thought that the Worse Is Better point of view
            had a bit of a YAGNI feel about it, but now I think that it's the
            Customer's job to decide whether or not to deal with less common
            circumstances, so neither side is very XPish.

            Completeness: again, Customer decisions, neither side is very XPish.


            So I don't buy it. I'm not sure that XP comes down on either side of
            that particular argument.

            David Carlton
            carlton@...
          • Adam Sroka
            ... snip ... Ditto. The article refers to something very different than XP. I m not convinced that the author was even trying to solve the same problem we are.
            Message 5 of 11 , Apr 30, 2007
            • 0 Attachment
              On 4/30/07, David Carlton <carlton@...> wrote:
              >
              >
              >
              >
              >
              >
              > On Mon, 30 Apr 2007 08:22:00 -0400, "Matt Heusser" <matt.heusser@...> said:
              >
              > > Yes, but the formal methods people were trying to do "The Right
              > > Thing" (TRT) whereas extreme programming takes the track of "Worse
              > > Is Better."
              >
              > XP doesn't feel very "Worse Is Better" to me: Worse Is Better doesn't
              > have rules taken to extremes the way XP does, I think. From the link
              > you gave:
              >
              > > http://www.jwz.org/doc/worse-is-better.html
              >
              >
              snip
              >
              > So I don't buy it. I'm not sure that XP comes down on either side of
              > that particular argument.
              >
              >

              Ditto. The article refers to something very different than XP. I'm not
              convinced that the author was even trying to solve the same problem we
              are.

              OTOH, his conclusion is agile in at least one sense: he suggests that
              releasing Unix and C in a state that provides some functionality (50%
              in his estimation) will allow them to spread virally, and that later
              more functionality can be added (up to 90%) when the demand is high
              enough. This is good business, and it sounds a lot like "release
              early, release often" to me.
            • Ron Jeffries
              ... Dick Gabriel is a wonderful and brilliant man. His views of the universe are far darker than mine, however. I do not fully agree with what Worse is Better
              Message 6 of 11 , Apr 30, 2007
              • 0 Attachment
                Hello, Matt. On Monday, April 30, 2007, at 8:22:00 AM, you wrote:

                > http://www.jwz.org/doc/worse-is-better.html


                > ----> I quite seriously believe that worse-is-better should be considered
                > part of the Software Development Foundation Literature, right up there with
                > No Silver Bullets, Learn to Program in Ten Years, Why Does Software Cost So
                > Much, Cargo-Cult Software Engineering, and PeopleWare. If you haven't read
                > it, I urge you to consider it.

                Dick Gabriel is a wonderful and brilliant man. His views of the
                universe are far darker than mine, however.

                I do not fully agree with what Worse is Better seems to imply,
                despite that it is historically accurate.

                Maybe it's just that I don't want to believe.

                Ron Jeffries
                www.XProgramming.com
                Adapt, improvise, overcome.
                --Gunnery Sergeant Tom Highway (Heartbreak Ridge)
              • christrobridge
                I think this is confused. Perhaps this is related to the fact that Formal Methods tend to be used in circumstances where the right thing is very important?
                Message 7 of 11 , May 2, 2007
                • 0 Attachment
                  I think this is confused. Perhaps this is related to the fact that
                  Formal Methods tend to be used in circumstances where 'the right
                  thing' is very important? - eg safety/life critical applications.

                  There is no reason why agile techniques can't be applied to formal
                  methods, so in a sense your comparing apples and oranges.

                  Formal methods (using a 'formal' language) might actually have added
                  benefits as you may be able to verify pre/post condition relationships
                  for all inputs rather than just spot cases, as happens with unit
                  testing. Then again, that might be beyond the proof checker... or
                  even just not computable.

                  I think there are several reasons why formal methods haven't taken
                  off. One is the cost of using them, another is the level of technical
                  skill/ability required is greater than for the more popular languages.

                  I think the great flaw in the 'Formal Methods' vision is that it
                  missed the (agile) point that a large part of the software development
                  problems is people not knowing what they want. It also overlooks the
                  possibility that people might actually make errors in the specification...

                  The lack of consistency (and formality) in the 'real world' may be a
                  problem too. It's one thing to validate that your formally generated
                  code is correct for a specific target, but the continual change
                  occurring to most platforms these days presumably precludes them?

                  Chris

                  --- In extremeprogramming@yahoogroups.com, "Matt Heusser"
                  <matt.heusser@...> wrote:
                  >
                  > Paolo Bizzarri Asked:
                  >
                  > >Now, it has been an interesting question (at least for me) why formal
                  > >methods have got so little success, whereas XP have got so much more
                  > >success. Both fields were practiced by smart people, interested in
                  > >producing better code.
                  > >
                  >
                  > Yes, but the formal methods people were trying to do "The Right
                  Thing" (TRT)
                  > whereas extreme programming takes the track of "Worse Is Better."
                • Chris Wheeler
                  ahem, ..Uhm..what are formal methods?...in all my years, I ve never used anything I ever called formal
                  Message 8 of 11 , May 2, 2007
                  • 0 Attachment
                    ahem, <shuffles feet, embarrassingly looks elsewhere>..Uhm..what are formal
                    methods?...in all my years, I've never used anything I ever called 'formal
                    methods'...Is this the whole 'prove correctness' thing that I slept through
                    in university?

                    Chris.

                    On 5/2/07, christrobridge <chris@...> wrote:
                    >
                    > I think this is confused. Perhaps this is related to the fact that
                    > Formal Methods tend to be used in circumstances where 'the right
                    > thing' is very important? - eg safety/life critical applications.
                    >
                    > There is no reason why agile techniques can't be applied to formal
                    > methods, so in a sense your comparing apples and oranges.
                    >
                    > Formal methods (using a 'formal' language) might actually have added
                    > benefits as you may be able to verify pre/post condition relationships
                    > for all inputs rather than just spot cases, as happens with unit
                    > testing. Then again, that might be beyond the proof checker... or
                    > even just not computable.
                    >
                    > I think there are several reasons why formal methods haven't taken
                    > off. One is the cost of using them, another is the level of technical
                    > skill/ability required is greater than for the more popular languages.
                    >
                    > I think the great flaw in the 'Formal Methods' vision is that it
                    > missed the (agile) point that a large part of the software development
                    > problems is people not knowing what they want. It also overlooks the
                    > possibility that people might actually make errors in the specification...
                    >
                    > The lack of consistency (and formality) in the 'real world' may be a
                    > problem too. It's one thing to validate that your formally generated
                    > code is correct for a specific target, but the continual change
                    > occurring to most platforms these days presumably precludes them?
                    >
                    > Chris
                    >
                    > --- In extremeprogramming@yahoogroups.com, "Matt Heusser"
                    > <matt.heusser@...> wrote:
                    > >
                    > > Paolo Bizzarri Asked:
                    > >
                    > > >Now, it has been an interesting question (at least for me) why formal
                    > > >methods have got so little success, whereas XP have got so much more
                    > > >success. Both fields were practiced by smart people, interested in
                    > > >producing better code.
                    > > >
                    > >
                    > > Yes, but the formal methods people were trying to do "The Right
                    > Thing" (TRT)
                    > > whereas extreme programming takes the track of "Worse Is Better."
                    >
                    >
                    >
                    >
                    > To Post a message, send it to: extremeprogramming@...
                    >
                    > To Unsubscribe, send a blank message to:
                    > extremeprogramming-unsubscribe@...
                    >
                    > ad-free courtesy of objectmentor.com
                    > Yahoo! Groups Links
                    >
                    >
                    >
                    >


                    --
                    --
                    Chris Wheeler
                    chriswheeler.blogspot.com
                    coach, programmer & practitioner


                    [Non-text portions of this message have been removed]
                  • christrobridge
                    ... formal ... formal ... through ... Probably ;-). I did a quick revision on wikipedia. It s to do with applying mathematical techniques to prove that final
                    Message 9 of 11 , May 2, 2007
                    • 0 Attachment
                      --- In extremeprogramming@yahoogroups.com, "Chris Wheeler"
                      <christopher.wheeler@...> wrote:
                      >
                      > ahem, <shuffles feet, embarrassingly looks elsewhere>..Uhm..what are
                      formal
                      > methods?...in all my years, I've never used anything I ever called
                      'formal
                      > methods'...Is this the whole 'prove correctness' thing that I slept
                      through
                      > in university?
                      >
                      > Chris.

                      Probably ;-). I did a quick revision on wikipedia.

                      It's to do with applying mathematical techniques to prove that final
                      system meets the requirements. This typically entails using languages
                      that have their semantics defined formally (mathematically?). If this
                      is done then there is some hope of getting answer to questions such as
                      whether two different programs are semantically equivalent, or the
                      truth of logical statements concerning the program.

                      In theory you'd hope most languages have a sound semantic definition,
                      but C and C++ actually avoid this deliberately for various reasons (or
                      at least defer the decision to particular implementations).

                      Chris
                    • John Roth
                      The big problem with Formal Methods as I see it today is that it s just too expensive to apply except in areas where the additional correctness/reliability
                      Message 10 of 11 , May 2, 2007
                      • 0 Attachment
                        The big problem with "Formal Methods" as I see it
                        today is that it's just too expensive to apply except
                        in areas where the additional correctness/reliability
                        is worth the cost.

                        I've commented on the relationship between
                        formal methods and TDD before, so to repeat:
                        assertions could be dropped into the TDD process
                        in exactly the same way tests are included now.
                        The difficulty is that there is no theorem prover
                        which can validate all assertions in a program of
                        reasonable size (about 100 kloc) within the TDD
                        window for running tests (that is, about 15 seconds)
                        for a useful language (e.g. Java). If anyone cares to
                        write one, it would take over the development world
                        the same way xUnit has taken it over today.

                        John Roth


                        ----- Original Message -----
                        From: "christrobridge" <chris@...>
                        To: <extremeprogramming@yahoogroups.com>
                        Sent: Wednesday, May 02, 2007 8:26 AM
                        Subject: [XP] Re: Success of XP over Formal Methods


                        I think this is confused. Perhaps this is related to the fact that
                        Formal Methods tend to be used in circumstances where 'the right
                        thing' is very important? - eg safety/life critical applications.

                        There is no reason why agile techniques can't be applied to formal
                        methods, so in a sense your comparing apples and oranges.

                        Formal methods (using a 'formal' language) might actually have added
                        benefits as you may be able to verify pre/post condition relationships
                        for all inputs rather than just spot cases, as happens with unit
                        testing. Then again, that might be beyond the proof checker... or
                        even just not computable.

                        I think there are several reasons why formal methods haven't taken
                        off. One is the cost of using them, another is the level of technical
                        skill/ability required is greater than for the more popular languages.

                        I think the great flaw in the 'Formal Methods' vision is that it
                        missed the (agile) point that a large part of the software development
                        problems is people not knowing what they want. It also overlooks the
                        possibility that people might actually make errors in the specification...

                        The lack of consistency (and formality) in the 'real world' may be a
                        problem too. It's one thing to validate that your formally generated
                        code is correct for a specific target, but the continual change
                        occurring to most platforms these days presumably precludes them?

                        Chris

                        --- In extremeprogramming@yahoogroups.com, "Matt Heusser"
                        <matt.heusser@...> wrote:
                        >
                        > Paolo Bizzarri Asked:
                        >
                        > >Now, it has been an interesting question (at least for me) why formal
                        > >methods have got so little success, whereas XP have got so much more
                        > >success. Both fields were practiced by smart people, interested in
                        > >producing better code.
                        > >
                        >
                        > Yes, but the formal methods people were trying to do "The Right
                        Thing" (TRT)
                        > whereas extreme programming takes the track of "Worse Is Better."
                      • Steve Freeman
                        ... The interesting bit about Worse Is Better is that the authors had the genius or luck (or both) to implement exactly the right abstractions to make Unix
                        Message 11 of 11 , May 3, 2007
                        • 0 Attachment
                          On 1 May 2007, at 03:29, Ron Jeffries wrote:
                          > Dick Gabriel is a wonderful and brilliant man. His views of the
                          > universe are far darker than mine, however.
                          >
                          > I do not fully agree with what Worse is Better seems to imply,
                          > despite that it is historically accurate.
                          >
                          > Maybe it's just that I don't want to believe.

                          The interesting bit about "Worse Is Better" is that the authors had
                          the genius or luck (or both) to implement exactly the right
                          abstractions to make Unix and C worth the trouble, same with Berners-
                          Lee and the Web. There are plenty of systems out there which are just
                          "Worse", so that's not a qualification in itself :)

                          S.

                          Steve Freeman
                          M3P Limited.
                          http://www.m3p.co.uk

                          Winner of the Agile Alliance Gordon Pask award 2006
                        Your message has been successfully submitted and would be delivered to recipients shortly.