Re: XP Requirement Analysis?

From: Ilja Preuß (it_at_iljapreuss.de)
Date: 10/12/04 

Date: Tue, 12 Oct 2004 15:19:31 +0200

Mark Nicholls wrote:
>>> If I ask you to write a test, you will ask me what I want you to
>>> test, and how that behaviour is exposed...i.e. you will want me to
>>> the analysis and design.
>>
>> Analysis, yes; design no.
>
> if we create a method signature...to me that is design.

Yes. I will decide on that while writing the test - just tell me what
behaviour you want. And I actually might change it once the test runs...

>>> Analysis then design then encode then refactor, this isn't new to
>>> me, it's just iterative development.
>>
>> I think the main difference is not in the practices, but in the
>> philosophy. Even with iterative development, traditionally people
>> will want to get the design "as right as possible" before starting
>> to code
>
> Again I think this is a mild misrepresentation.
>
> I want to get it as right as possible given that the cost of that is
> not greater than the benefit of doing something else.

Well, yes, of course.

What seems to be rather revolutionary to many people seems to be the
suggestion that, when using a certain set of practices in concert with
modern technology, the cost of trying to get the design right upfront is
virtually always at least as high as getting to the right design by starting
with a minimal design and improving it continuously.

> if the
> risk is that the development team may not actually understand what
> the client wants...then I would try to mitigate there, it would not
> be sensible for me to dive into testing, if I wasn't sure what I
> wanted to test.

Well, as an aside, one way to get the understanding would be to write the
tests together with the client...

> The driver to me is risk/cost/benefit.

Naturally. The question is how to deal with a specific risk, though. To
understand a requirement, do you let the customer check a requirements
document, or a running system?

>> - they might refactor,
>> but will see it as a necessary evil instead of the main practice to
>> get to a good design. They might write automated tests, but they
>> will see it more as a practice to find bugs instead of preventing
>> them. And they typically will want their testing to be minimally
>> invasive, in contrast to specifically using the tests to form the
>> code.
>>
>
> Agreed.

For those people, it is likely that they will have some reservations about
doing XP. Perhaps the practices aren't elementary different, but doing them
would require from them to question some deeply held believes - "never touch
a running system", "tests can't prevent bugs, only find some", etc.

I think that is why XP often feels revolutionary - not because of the
practices, but because of the assumptions you need to make to feel save
using them.

>>>> So are you saying that deciding on part of the design, coding that
>>>> part, and *then* testing and debugging it until it works, is
>>>> atypical for traditional software development?
>>
>> Sadly you didn't reply to this...
>
> What do you mean by testing...

Good question - and I don't have an answer at hand... :o

>> Well, every method is more than just being iterative, of course. And
>> it's part of that "more" that's different.
>
> OK, that's fine, I started this because of statements about XP
> contradicting the logic of RAD

I must have missed that, sorry.

> to me it doesn't, it builds on it,
> and by taking a club to RAD we may simply be pushing ourselves into
> entrenched positions.

I don't know enough about RAD to comment.

But again in general I don't see an inherent contradiction between building
on something existing and being revolutionary...

>> As far as I know, there is no contradiction between evolution and
>> revolution. A small step in an evolution can often have revolutionary
>> consequences - especially in complex systems.
>
> evolutions can create revolutionary consequences...but the process is
> evolving, claiming it's a revolutionary process though looses any
> potential for consensus

Well, perhaps those people claiming that XP "is a revolutionary process"
just mean something different from what you understand it to mean?

>>> If you write all the tests before writing any code,
>>
>> Just for the record: I don't - that's not what TDD is about.
>
> then I am bamboozled slightly.

Are you?

>>> I would suggest
>>> that the normal use of assertion inside code, reduced the iteration
>>> even further
>>
>> How would they do that??? Wouldn't you still need outside test code
>> that called the production code?
>
> yes, but by embedding you tests in your code means that you are
> testing all code all of the time....that's as clear as mud!

If you don't have external tests, the first time the assertions would be
executed would be in production!

> If you are writing a unit test for class A, and A uses B, and B is
> stuffed full of assertions, then the test for A does some testing on
> B. So in a sense writing A is in fact writing a test for B. XXP!

The same is true without assertions. When A uses B and B doesn't work
correctly, A doesn't wotk correctly either.

>>> is this XXP, or just the use of assertions in
>>> software development?
>>
>> If "taken to to the extremes", it's called Design By Contract, is
>> orthogonal to TDD as far as I can tell, and far from being common
>> practice. It's certainly worth a look.
>
> No I'm talking about embedding assertion inside the code, as apposed
> to outside in the tests....

What makes you think that I wasn't???

>>> I do see interesting approaches, new ideas, some of which may be
>>> sensible, some not,
>>
>> Of which you can't be sure before you tried, I'd add...
>
> True, but as I pointed out, in order to do something, I need to have a
> reasonable sense that it is better than what I'm doing now....I could
> hop to work...I've never tried, but I think walking is better.

I think I tried that in my early years of school... ;)

And I was seriously thinking about trying inline skates when they became
popular here some years ago.

> I have and use n-unit...I see it as a test harness. I follow many of
> the practices of RAD...so I should be 90% along the XP, BP route.

That doesn't mean that you get 90% of the benefits, though. Actually it
doesn't even mean that it needs to feel similar to TDD/XP at all...

>> Today, the IDE checks the syntax as fast as I type; and running an
>> extensive suite of tests is a matter of seconds. That considerably
>> changes the forces of software development.
>>
> I like VB6 as well!

:eek: ;)

Cheers, Ilja

Relevant Pages

  • Re: XP Requirement Analysis?
    ... >> the analysis and design. ... > I think the main difference is not in the practices, ... Like writing some code and some tests. ... >> there is no revolution, ...
    (comp.object)
  • Re: How much OO is too much OO?
    ... Others maintain that most of these practices are irrelevant until/ ... encasulate that part of the design. ... amount of abstract classes, interfaces, and indireciton mechanisms. ... once your dependencies leak between name spaces. ...
    (comp.object)
  • Re: Little design mistakes that can be easily avoided (2): Listenning to CELKO (and CELKO alikes)
    ... Disseminating product information with wax of science is not the same ... one merely needs to discover the constraints placed on the ... Design practices, both best practices and others, sometimes elucidate ...
    (comp.databases.theory)
  • advise on best practices guides and projects
    ... I am having some problems with certain practical aspects of OO design and programming. ... When I was programming C, I studied the Apache2 web server code and learnt a lot about how to make good C code and. ... Now I want to do a similar thing in java. ... I havent done that many java projects yet, so I know I need more practice, and that is why I am asking for advice on best practices guides and more importantly best practices projects, i.e. one or two complete or living project where I can study excellent java code written by excellent java programmer and see how others solve the practical issues of OO design and programming ...
    (comp.lang.java.help)
  • Best Practices for Hardware Engineers
    ... I have a list of Best Practices for Hardware Engineers that I ... Try a Top Down design approach instead of Bottom Up ... team does he/she get introduced on how the design teams develop ...
    (sci.electronics.design)