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

Customer Tests.........was RE: [XP] Re: Ship It

Expand Messages
  • Kay A. Pentecost
    Hi, Ron, Grady, Dossy, Wow. Thanks for just the information I ve been looking for. I m starting (any day now) my little bookstore app for my Customer... and
    Message 1 of 82 , Sep 1, 2002
    • 0 Attachment
      Hi, Ron, Grady, Dossy,

      Wow. Thanks for just the information I've been looking for.

      I'm starting (any day now) my little bookstore app for my Customer... and
      one of the things that has been holding me back (translation: allowing me to
      procrastinate) is Customer Tests. My Customer doesn't know how to be a
      Customer yet, she's still saying things like "You better make it work, or
      else." Since this is a pro bono job, I don't know what or else
      means...<grin>

      Back to the subject.

      One of the stories is "Display all the information about a book." My unit
      tests, already in place, with the code that passes them, refer to a subset
      of the data...in other words, I create a book and its attributes, and then
      test to see if it comes back correctly. Whoops. Reverse that. I tested to
      see if it came back correctly, and then created the object, of course.

      Now, on the Customer Tests... She wants to know how many books were written
      by, say, Ron Jeffries. If, in the future, Ron writes another book, this
      will change. So do the Customer Tests point to a separate data store?

      Same thing with entering a new book. Once it's entered, it's in the data
      store, whatever that is, and I can't automate entering the same book
      twice...

      I'm confused.

      Please unconfuse me.

      Thanks!

      Kay

      > -----Original Message-----
      > From: Ron Jeffries [mailto:ronjeffries@...]
      > Sent: Sunday, September 01, 2002 12:36 AM
      > To: extremeprogramming@yahoogroups.com
      > Subject: Re: [XP] Re: Ship It
      >
      >
      > Around Sunday, September 1, 2002, 12:21:32 AM, Steve Willer wrote:
      >
      > > Your point and Ron's was that the requirements of a testing tool for the
      > > particular person who posted the question wasn't known because he hadn't
      > > outlined any tests.
      >
      > That was not my point, though I believe it was Dossy's. My point was,
      > and is, that in the absence of a tool, you still need tests.
      > Therefore, in the absence of a tool, you must code them.
      >
      > It is my experience that where this is done, the cost of testing does
      > not become excessive, probably because programmers are really good at
      > finding easy ways to do boring things. And because refactoring really
      > does work.
      >
      > Ron Jeffries
      > www.XProgramming.com
      > The Great and Powerful Oz has spoken.
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    • 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.

        sb

        --- In extremeprogramming@y..., "Bryan Dollery" <Bryan.Dollery@C...>
        wrote:
        > 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
        70%).
        > >
        > > [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
        truth
        > in it.
        >
        > Of course, I may have not made the context too obvious. I meant
        everything
        > *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
        them,
        > 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
        tools,
        > 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
        recently?
        >
        > 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,
        depends
        > on technology. I know that Jones' data may not be a representative
        sample,
        > 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
        business
        > 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.