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

RE: [XP] Re: Ship It

Expand Messages
  • mfeathers@mindspring.com
    ... It s not like we are talking about something big. Last summer, I bootstrapped an xUnit in an hour when I realized I didn t have one on my laptop during
    Message 1 of 82 , Sep 1, 2002
    • 0 Attachment
      On Sat, 31 Aug 2002 20:25:14 -0700 "Booch, Grady" <egb@...> wrote:

      > > In order to implement automated testing, you
      > must first understand the
      > > test to be automated. The precondition is
      > that such a test exists.
      > [egb> ] The basic nature of automated testing
      > is invariant relative to the
      > genre of test to be automated; there exist GUI
      > testing tools, non-GUI tools,
      > and the like. There indeed exist meta-test
      > tools - tools that manage the
      > activity of running tests and the configuration
      > of the tests themselves.
      > [egb> ] There's a long history of testing
      > methodology; why do you want to
      > recreate everything for every project?

      It's not like we are talking about something big. Last summer, I bootstrapped
      an xUnit in an hour when I realized I didn't have one on my laptop during
      vacation (it was one of those travel lulls, you know). Frankly, I did more
      than I needed to get a couple of tests going, Live and learn.

      The issue is, these things are simple. Writing one for your specific needs is
      often easier than figuring someone else's out.

      Michael Feathers (it's not writing emacs for goodness sake)
    • stewartbaird
      Hi Bryan I agree with your comments about the sociology aspects of software development - Peopleware made that point 15 years ago. Also, I hold to the view
      Message 82 of 82 , Sep 30, 2002
      • 0 Attachment
        Hi Bryan

        I agree with your comments about the sociology aspects of software
        development - Peopleware made that point 15 years ago. Also, I hold
        to the view that software development is more ART and than science.
        As a wanna-be artist, I throw away most of what I paint on the way to
        my next masterpiece. (Ok, I don't *actually* throw it away- I file it
        in a drawer).

        The empirical nature of design is where XP shines for me. Its fun
        too, watching users create their own solutions. We just take notes
        in the form of code.


        --- In extremeprogramming@y..., "Bryan Dollery" <Bryan.Dollery@C...>
        > Hi,
        > Grady followed nicer posting practices, and wrote:
        > > > We have to - everything that existed before XP contributed to
        > > the crisis,
        > > > and the high failure rates (variously quoted as between 50% and
        > >
        > > [egb> ] oh my; you are in effect saying that all that preceded
        > > XP is bad and
        > > evil; all that follows XP is well and good. I do embrace XP - but
        at the
        > > same time do not find it necessary to reject all that came before it.
        > This is why we call it Extreme
        > :-)
        > It did come across a bit strong, but I do believe that there is some
        > in it.
        > Of course, I may have not made the context too obvious. I meant
        > *in the software process domain*. So, I wasn't saying that the
        concepts of
        > modularisation are bad, just the order in which people tend to apply
        > and the focus they give them. Similarly testing tools, not bad as
        such, but
        > used badly (and in some cases based upon bad ideas - gui recording
        > yeuch).
        > > > Also, each project is unique, why would you want to constrain
        > > a project's
        > > > optimal evolutionary path by constraining some part of it a priori?
        > >
        > > [egb> ] But there are pragmatic constraints. Shall I eliminate the
        > > artificial constraint of the set of programming languages that I
        > > may choose
        > > from, and instead write my own language first? The existing ones
        are so
        > > confining... What about operating systems? Shall I write my own so
        as to
        > > permit my project to follow its optimal evolutionary path?
        > Military
        > Space Exploration
        > Telecommunications
        > Isn't that almost exactly what happened in these domains up until
        > US Mil: Current languages are crap, lets build our own, and call it ADA
        > Grady: Oh, that means I'll have to teach you all how to program in it
        > efficiently
        > So, it's been done before - that's where most of the current OSs and
        > languages came from.
        > Does reusing an existing platform increase your productivity - yeah, but
        > the cost seems to be 50%-70% of project failure - which would mean 0%
        > productivity. You have a tradeoff, as you mention below, between
        cost and
        > risk.
        > The point is, if you don't want to repeat the mistakes of the past, you
        > have to start by not repeating the past.
        > > [egb> ] Starting with a completely blank page is typically worse than
        > > staring with a page for which you at least know where the edges lie.
        > > Ultimately, software development is an engineering problem,
        wherein one
        > > finds a balance among the forces upon the project.
        > I disagree - software development is a sociology problem, about how
        to get
        > people to do engineering effectively. There is clear evidence for this -
        > Jones points out that project success or failure rarely, if ever,
        > on technology. I know that Jones' data may not be a representative
        > but it's the best we have at the moment, and it's indications are
        clear -
        > software development is sociology.
        > Writing good code is an engineering problem. Getting people to do this
        > efficiently is a sociology problem. Putting in place the funding and
        > facilities to write code is an business problem. Discovering the
        > fundamental rules and techniques that the programmers base their
        > engineering discipline on is an academic task. Ensuring that there is a
        > national (and to some extents global) economy that supports that
        > is an economic and governmental problem.
        > My point, to reiterate, is that just because engineering is involved
        > somewhere in the mix doesn't make this an engineering problem. You can't
        > engineer societies, and this seems to be the major mistake that
        people have
        > made that has led to the software crisis and our abysmal success rate.
        > Cheers,
        > Bryan
      Your message has been successfully submitted and would be delivered to recipients shortly.