Re: XP Requirement Analysis?
From: Mark Nicholls (nicholls.mark_at_mtvne.com)
Date: 10/11/04
- Next message: Mark Nicholls: "Re: XP Requirement Analysis?"
- Previous message: Robert C. Martin: "Re: largest storage"
- In reply to: Ilja Preuß: "Re: XP Requirement Analysis?"
- Next in thread: Ilja Preuß: "Re: XP Requirement Analysis?"
- Reply: Ilja Preuß: "Re: XP Requirement Analysis?"
- Reply: paul campbell: "Re: XP Requirement Analysis?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 11 Oct 2004 13:20:37 +0100
>
> > 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.
>
> > 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.
Like writing some code and some tests. Or checking back with the client that
where we've gone is sort of what they were thinking...all sorts of other
stuff.
At the heart of iterative development is risk analysis...if the risks are
associated with the code...i.e. it is demanding in some sense,
architecturally or performance or whatever, I go there next...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.
The driver to me is risk/cost/benefit.
> - 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.
> But perhaps all old news to you. In my experience, it isn't to the
majority
> of developers, though.
It's not all old news, as I've said if we get to 90% of this is old hat that
we can agree on, then that is good. We can then argue about the last
10%....and maybe agree on some of that as well.
>
> >> 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...there seems to be an idea that we write the
code and then create tests, I don't believe this atypical or typical.
Certainly as a C programmer asserts explicitly exist as part of the micro
development process, compiling often (testing?) is normal, running against a
test harness (testing?) is quite normal....I accept TDD may move even
further, but to stylalise typical, as waterfall, would be unhelpful....at
least to me.
>
> >>> iteractive development existed long
> >>> before XP was a twinkle in anyones eye.
> >>
> >> I don't remeber anyone stating something different. Perhaps XP is
> >> more than "just" iterative development.
> >
> > That's fine....perhaps it is...the statements seem to imply not that
> > it is more, but that is is different.
>
> 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, 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.
>
> > In A we do B, in C we do D.
> >
> > rather than
> >
> > in A we do B, in C we do B and D.
> >
> > there is no revolution, just evolution.
>
> 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...XP to me is XRAD, that should be a compliment, not a
problem.
>
> > i.e. we should be able to consensually agree about B(!) and then go
> > on to argue about the value of D
>
> The value of a process isn't simply the sum of the values of its
practices.
> It's to a great amount defined by its philosophy, by its values and their
> impact on why, when, how and how much the practices are used, and how they
> interact.
Then we can discuss the last 10%.
>
> Therefore I'm not sure thar "agreeing about B" buys us much.
>
90%.
>
> >>> It is called iterative development, or spiral development lifecycle.
> >>
> >> That still has testing *after* coding in the cycle, if I remember
> >> correctly. It still has design before coding inside an iteration,
> >> hasn't it?
> >
> > I agree, but I cannot see how you write a test before you know what
> > to test or what the thing we want to test looks like
>
> I only need to know about what it looks from the outside, I can decide on
> that while writing the test, and that decision can be a rough first cut
that
> gets improved once I have a green bar.
OK.
>
> >, I accept that
> > you are potentially moving the test before writing the
> > implementation, where 'traditionally' it would be done at the same
> > time via assertions or after via unit testing.
>
> Yes. And that makes a *big* difference. It's possibly as revolutionary as
> physicians washing their hands before the surgery instead of only
> afterwards.
maybe.
>
> > 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.
>
> > 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 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!
>
> > 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....it's old hat....but very powerful.
>
> > 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 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.
>
> > but whenever people come down to identify what
> > those actual differences are, they seem to be an adaptaption or new
> > implementation of existing thought
>
> Well, yes. And still until recently they weren't used that much in that
> specific symbiotic combination.
Possibly, possibly not....RAD was since the 90's and is big now...very
big....probably the norm....and 90% in the same line as XP etc.
>
> > that's good and
> > fine......but don't oversell it
>
> How do you know wether something is oversold?
When people start claiming revolution when there is only evolution, when
they start rewriting history in order to make the claims seem better, when
the defintion of typical is waterfall and not RAD (at least as well).
how do you know it isn't...I feel it is...which is why we get 300+ posts
with people falling into entrenched positions.
>
> > ....it isn't the silver bullet,
>
> That's true. For many teams it seems to improve things somewhat, though.
That's good, genuinely. I'd be interested to know what they were doing
before...but its still good.
>
> > if XP
> > reduces the iteraction time in evolutionary prototyping and
> > iteractive development process then good
>
> I think XP does a little bit more than that....
maybe, maybe not...thats still a good thing to me though.
>
> > ...but it doesn't negate the
> > value of those concepts.
>
> Did someone say it did???
it all started....as these things often do....with a relatively innocent
swipe at RAD....I now I'm embroiled.
I usually steer clear of process discussions as I don't particularly
subscibe to any as a rule.
>
> > the logic and value of
> > them could be traced back into the established knowledge of 40 years
> > of software experience....
>
> There is one very significant difference: 40 years ago, feedback was slow
> and costly - it was expensive to only compile a program and it took ages.
> (That's what I hear, at least - I didn't exist at that time.) Therefore it
> was important to check everything extensively before going the next step.
Which is why I subscribe to itterative development.
>
> 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!
oh no, I've just undermined all potential creditability.
Mark
- Next message: Mark Nicholls: "Re: XP Requirement Analysis?"
- Previous message: Robert C. Martin: "Re: largest storage"
- In reply to: Ilja Preuß: "Re: XP Requirement Analysis?"
- Next in thread: Ilja Preuß: "Re: XP Requirement Analysis?"
- Reply: Ilja Preuß: "Re: XP Requirement Analysis?"
- Reply: paul campbell: "Re: XP Requirement Analysis?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
