Re: XP Requirement Analysis?
From: Mark Nicholls (nicholls.mark_at_mtvne.com)
Date: 10/08/04
- Next message: Universe: "Re: Book reccomendations"
- Previous message: Universe: "Re: On XP and debate, or the lack thereof"
- In reply to: Phlip: "Re: XP Requirement Analysis?"
- Next in thread: Laurent Bossavit: "Re: XP Requirement Analysis?"
- Reply: Laurent Bossavit: "Re: XP Requirement Analysis?"
- Reply: Rich MacDonald: "Re: XP Requirement Analysis?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 8 Oct 2004 18:57:31 +0100
>
> > nice....I also think sitting down for half an hour with a pencil and
piece
> > of paper is very useful.
>
> Of course it is. So is checking out a sand-box of your project and
screwing
> with it for a while. Then copy the best back into your real project.
I agree, I have a think, and then a mess about, and then I think
either...nope, you've disappeared up your arse again or, yippee, I can now
delete 10% of the code from my app and plan.
>
> (And my dynamic attractor parable is _not_ about inspiration, or beliefs,
> but they can help.)
>
I didn't really understand it, so I can't comment.
> When an existing design needs to be encoded via TDD, I get the mental
image
> of an old-fashioned clothes wringer. You take wet dripping clothes, run
them
> through the wringer, and it squeezes out most of the water.
>
> To squeeze any latent cruft out of a pre-existing design, return to your
> production project, and use TDD to force the same design to emerge. Of
> course you can cheat a little. Given an early choice what to refactor you
> can lead the design towards your plan a little.
>
> However, if you can't find a way to add the last few design elements that
> you planned, without exceeding the number of features you currently need,
> you learned something.
>
> > > - <10 edits between correctly predicting a test run
> >
> > yep....this is 'extreme' at the very least if it is a rule.
>
> We don't have "rules" we have "principles".
>
oh no, here we go again.....hueristics you mean? (principles make me shudder
slightly, as there seems to be a cultural gap as to the meaning).
> In this case, the <10 edits rule^W principle could have come first, and it
> could have generated the TDD principle. Or, the TDD rules can come first,
> and generate the <10 edits principle.
I drank 2/3rds of a bottle or red wine last night, red wine always does my
head in, so I'm not with the above, but it may be me.
>
> > > - Undo to get rid of unexpected failures
> >
> > yep...normally one would expect to edit/debug/correct failure rather
than
> > remove them as a rule, that is 'different'.
>
> Sometimes production code is very near to what you need, so you just debug
a
> little, or fix an obvious typo. You always have the _option_ to Undo, and
> the <10 edits principle forces you to only make changes that you can
> remember, so you could even Undo manually.
OK, now I see the mentality about the <10 edits, and actually I can believe
there is a place for it.
>
> These principles, used with other XP situations like pair programming,
> prevent those long hideous open-ended bug hunts.
reduce? maybe, maybe not, I wont argue because I am ignorant of such
projects except via heresay.
>
> On a "traditional project" (in my experience), the longer you code, the
> slower you go. On a project following these principles, the longer you go
> the faster you go.
nope....'the longer you go'.....at what?
>
> > > - write a line of test to force a line of code
> >
> > hmmmmm, I still don't really believe this you see.
> >
> > to write the test, I must have an interface to an implementation, even
if
> I
> > have no implementation. So the interface *must* come first.
>
> Read my "nut_shell" paper.
I did browse, I admit to being tired and lazy at the moment, it's quite
long.
I apologise, I am probably not doing your argument justice....I'll have a go
on Monday.
>
> The interface _does_ come first. You write the simplest interface that
could
> be tested, and the decoupling starts here.
OK, but you need to know what that interface is, so you must do some
analysis and some requirements gathering and some design.
These must come before you write any client (test) or implementation
(potentially even a dummy).
>
> > In order to know what the interface is, I surely need to know something
> > about the problem in question, so I *must* have to do some sort of
> analysis.
>
> Yep. Just enough to get to the interface, to the test, and to the feature.
I've had this argument with Lahman.........
If you've got the interface....then you've got the abstraction....you've
done the analysis.
If you may out the interfaces of the system (concrete class = implementation
+ interface) it looks like a big abstract model of your system.
You are doing bog standard SD.....with some knobs on....and I'm not too sure
about all of the knobs.
>
> Here's a dirt simple example:
>
> int main()
> {
> Source aSource("a b\nc, d");
> string
> token = aSource.pullNextToken(); assert("a" == token);
> token = aSource.pullNextToken(); assert("b" == token);
> token = aSource.pullNextToken(); assert("c" == token);
> token = aSource.pullNextToken(); assert("d" == token);
> token = aSource.pullNextToken(); assert("" == token);
> // EOT!
> }
>
> From the tested interface, we can tell that Source is going to be an
object
> that parses strings, removes blanks, and returns tokens.
pullNextToken()
what does that do...how did you name it...how do you know what it
returns...how do you know what to pass it, how do you know what to test
for...i.e. you have some preconcieved idea of what it does.
It didn't pop out of the ether.
You designed it didn't you, you shouldn't be ashamed, we all have to do it
sometimes....hopefully most times.
And now you've just written a client a an implementation for it......it was
the test.
requirements
analysis.
design .....here comes some interfaces
coding....here comes client and implementations...including tests and dummy
implementations.
run tests.
maybe this is based on a misconception of what testing means when put in
things like iterative development. My interpretation is 'run tests' comes
after write some code. My practice has always been to embed the tests in the
micro coding process via assertions.
>
> That sounds too trivial to reflect real-world project needs, right?
I don't know....I have a sneaky feeling I've missed your point.
>
> ==> that's the point. it's trivial <==
>
> To avoid high-risk code, we start all tests low-risk, and only push the
risk
> up at need, to buy a business value.
RAD......!!!!!
spiral process...analysis..assess risk.....mitigate.....move
forward....analysis.....assess risk.....mitigate.....move
forward.......analysis.....assess risk.....mitigate.....move
forward.......analysis.....assess risk.....mitigate.....move forward.......
its good yes....it's not an XP knob though....it's an ordinary, accepted,
established RAD knob...its normal, natural and kind.
>
> > In order to do some sort of analysis, I must know what the system's
intent
> > is, so I *must* have to do some sort of requirements gathering.
>
> Yes. You start the project with a mission statement, a top-ten wish-list,
> and whatever verbiage the participants _feel_ like writing. Then your
> requirements-donor narrows in on the highest business value features, and
> you analyze them in bite-sized chunks.
see above....this I think it normal....except maybe you should be assessing
greatest risk v greated value......the idea being that you don't spent 18
months writing the new version of windows to find out that the kernel
architecture will not and cannot ever work.
>
> Because everyone in your business should have at least a nodding
> understanding of your business goals, the high business value features
> should be very obvious. Your receptionist should know them.
I agree this is normal.....unless you are not taking risk into account...in
which case it genuinely is different and probably foolhardy.
>
> However, lower-priority features won't be so obvious, and the minimal set
of
> them that maximizes business value is not obvious.
this is just economics.....Wealth of nations...Adam smith (17th
century).....stop when marginal revenue = marginal cost.
it's in RAD....under feature removal....i.e. cost and schedule is not always
obvious on day 1.
>
> Expecting requirements analysis, without code, to locate that minimal set
> adds incredible risk.
again your assuming some sort of waterfall process...that fell from favour
in about 1990.
>
> > I'm not saying waterfall, as I've said, we look in RAD and we see all
> sorts
> > of ways of doing fast, incremental gathering and analysis, and I believe
> > this is far from rare, in fact it may well be the dominant approach.
> >
> > So what are we left with?
> >
> > A more formalised approach to adding tests to our code....that's
probably
> > good.
>
> And a way to allow emergent design to propell - instead of interfere
with -
> incremental requirement analysis.
that sounds good...but I don't see it. Do you mean evolutionary prototyping
with the client in some sense...if so this is normal, standard
practice...not an XP knob.
>
> > My central criticisms of the extra stuff is this.
> >
> > I have long found that the most productive part of my day is walking to
> > work, walking home, and standing in the freezing cold smoking a
cigarette.
> > I have no emprirical evidence to back this up, just my personal
> experience,
> > so I might be talking about just me.
>
> I don't like to discuss the things that make me most productive among
> potential employers. ;-)
I have no cheque book....first rule of sales....identify the man who really
signs the cheques.
>
> > So why do I believe that these enforced absences from my keyboard are
the
> > most productive?
> >
> > because I can think.
> >
> > clearly.
> >
> > without the clutter of code and a keyboard.
> >
> > I can model and abstract, I can see new simpler ways of what I've spent
> the
> > last 2 hours 'evolving' in my development tools.
>
> Right. We call this either Sustainable Pace or Balanced Life.
genuine laughter.
I'll tell that to the wife, when I come home next in some sort of partial
nervous breakdown trying to finish something.
I call it analysis, infomal, unstructured.
>
> > Simplicity is the key, and I find *not* sitting in front of a computer
> with
> > a pencil and a piece of paper for thirty minutes to be the best way to
> > derive simplicity and *then* return to the toil at the keyboard.
> >
> > So if it works for you, fine, you may be in the majority, but I doubt it
> > will work for me.....though I do believe in small incremental
development,
> > there is a lower bound where any thought or analysis is wrung from the
> > process, there is a bigger picture that must be established or at least
> > sketched.
> >
> > In short, it seems to be a form of incremental code and fix....and that
> > probably is not as good as what I do now...sorry.
>
> Try it. You'l like it. ;-)
>
I think someone's put it in another post.....there always seems to be this
XP/Agile v's grumpy old men battle.....it's highly polarised and noone ever
says....'ooo actually that's not completely mad' or 'well actually now you
say that maybe that aspect of XP is debatable'.
I like testing.....if XP promotes testing thats a good thing.
I like comminication......if XP promotes testing thats a good thing.
I like small iteratice development......if XP promotes testing thats a good
thing.
But I also like promoting making people think and comminicate and draw rough
sketches of data architecture and system architecture and not do this with
the IDE open and the compiler whirring.
Unforunately I don't think XP does promote this, I think it may actually
undermine it.
- Next message: Universe: "Re: Book reccomendations"
- Previous message: Universe: "Re: On XP and debate, or the lack thereof"
- In reply to: Phlip: "Re: XP Requirement Analysis?"
- Next in thread: Laurent Bossavit: "Re: XP Requirement Analysis?"
- Reply: Laurent Bossavit: "Re: XP Requirement Analysis?"
- Reply: Rich MacDonald: "Re: XP Requirement Analysis?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
