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

Ship It

Expand Messages
  • Ron Jeffries
    OK, unbelievers. Here s the precis from today s addition to the Adventures in C# series. One iteration, around a dozen hours work, and we have automated
    Message 1 of 82 , Aug 31, 2002
    View Source
    • 0 Attachment
      OK, unbelievers. Here's the precis from today's addition to the
      Adventures in C# series. One iteration, around a dozen hours' work,
      and we have automated acceptance tests and a deployed application on
      what amounts to a pure GUI app.

      The first iteration is coming to a close. We have our story
      implemented, and it is running the first Customer Acceptance Test.
      There's only one thing left to do: ship the product.

      Go thou and do likewise.

      http://www.xprogramming.com/xpmag/acsShipIterationOne.htm

      Ron Jeffries
      www.XProgramming.com
      Speculation or experimentation - which is more likely to give the correct answer?
    • 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
      View Source
      • 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.