Re: XP Requirement Analysis?

From: Robert C. Martin (unclebob_at_objectmentor.com)
Date: 10/09/04 

Date: Sat, 09 Oct 2004 09:37:11 -0500

On Sat, 9 Oct 2004 08:24:23 +0100, "Richard Dell"
<rfdell@gotadsl.co.uk> wrote:

>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
>news:0ms8m0l9slmohje0octhj2v4si0magblkj@4ax.com...
>> On Wed, 06 Oct 2004 15:09:34 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote:
>>
>>>Rich MacDonald wrote:
>>>
>>>> Exactly. However, stable in the sense of bug-free, not stable in the
>>>> sense of changing.
>>>
>>>In traditional programming, you encode a design, and then debug until the
>>>behavior stabilizes. In XP you encode behaviors, and then refactor until the
>>>design stabilizes.
>>
>> Nicely stated!
>
>As someone who has written code all his life, but never to a specification drawn
>up by others, I infer from this that you would regard a legalistic contractual
>arrangement between customer and supplier as a BAD IDEA.

I don't know how you inferred that from the above. I don't have any
problem with a formal contract between customer and supplier. In a
software development context I think that contract needs to embody the
realities of software development and therefore cannot simply demand X
functionality for Y cost by Z date.

>I also infer that it is
>desirable for the supplier to have a real understanding of the problem in order
>to formulate a vision of where he is going, and to know when he has got there.

Not so much. It is important for the customer and supplier to agree
on the problem to be solved and the big picture constraints and
solutions. But the details can, and should, be left for a time when
there is more data.
 
>This seems to chime more with the cottage industry approach of the 1960s and
>1970s (widely seen as undisciplined and problematic) than the formal waterfall
>approach (such as SSADM) that emerged in the 1980s.

Again I'm not sure how you inferred that from the statement above.
However, you are expressing a common fear. Some folks fear that the
agile methods are just a return to the hacking of '60s. (Actually I
was writing code in the '60s and can testify that we did not hack. We
were as disciplined and professional as we knew how to be.)

>It also implies a smearing
>out of the distinctions between user, customer, architect and programmer to the
>ideal that they should all be in the same team.

Again, I don't know how you inferred that from the above. However,
that is also a common fear of agile development. Agile teams are not
smeared out into uniform roles. They do, however, work much more
closely together than traditional teams, and change hats more readily.

>Yet SSADM is still taught and
>contracts still common. Is waterfall dead, or merely moribund?

Waterfall is not dead; but it is dead wrong. The DoD research of the
late '70s and '80s showed conclusively that the more a project adheres
to a waterfall mentality the more likely it is to fail. The industry
is just now catching up to this conclusion.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
 but to set a limit to infinite error."
    -- Bertolt Brecht, Life of Galileo

Relevant Pages