Re: XP Requirement Analysis?

From: Mark Nicholls (nicholls.mark_at_mtvne.com)
Date: 10/07/04 

Date: Thu, 7 Oct 2004 17:11:33 +0100

> > The undelying process is not revolutionary, it does not contradict
> existing
> > thought, it builds on it, if we can both agree it is an example of
> iterative
> > development, we can argue about the specific implementation and it's
> value.
>
> If I return to the idea that testing FIRST is revolutionary, you will
point
> to numerous examples of folks writing tests before writing the code to
pass
> them. It's not just the "first" part that makes it revolutionary.

OK, I thought we'd agreed that really there was a tiny bit of requirements
gathering and analysis before we could do that.

>
> - work at the level of statements within methods, not entire methods
> - the fewest possible edits between testing, say 10 at the most
> - don't design until the tests pass
> - design by refactoring
> - force the design you plan to emerge
> - always correctly predict the result of the next test run
>
> Put together, nobody worked at that level of granularity. The inversion
goes
> beyond simply writing the test first.

ooo you said that word.

>
> To add a new feature, the test must fail for the correct reason. After it
> fails, perform the smallest possible edit to pass the test. After the test
> passes, refactor to recover from the poor design of that small edit.
>
> By "small" I mean you should be able to undo the edits manually, without
> using the Undo button (though you could). The edits should fit in your
> short-term memory.
>
> The inversion is you should pay more attention to whether a test fails for
> the correct reason than you should pay to the code that makes it pass.
When
> you force a Red Bar, and want to write a new feature, now is the time to
> step thru the code and see if its behavior is exactly what you expect.
> However, when you write code to pass the test, you are allowed to lie. If
> the test asks for 10, the new code could just return 10, without logic.
>
> Writing more assertions and more tests, to force out that lie, to make the
> simplest code that can pass all those tests also be the correct production
> code, is where analysis happens.
>

There is a lot here that makes sense...and I have seen before....and some I
haven't....and I stay open minded.

> You ought to try the TDD lifecycle with a small test project, and try to
> generate these effects for yourself.
>
I've been putting assert in code for 12 years+.
I use n-unit.
I have built dummy implementations for 8 years+ in order to run tests
against live code.

I still do some analysis up front in order to understand what the client
actually wants, I believe that direct communication between development and
client is the quickest way to establish some sense of the problem domain
without the obstruction of keyboard monitor code and test, I think it
reduces the early iterations to a 5 minute conversation rather than a 30
minute code and test cycle. Diminiting returns hit quick in any analysis
phase, and I have long believed that any attempt at exhaustive analysis is
doomed.

Relevant Pages

  • Re: XP Requirement Analysis?
    ... to numerous examples of folks writing tests before writing the code to pass ... - don't design until the tests pass ... the test must fail for the correct reason. ... By "small" I mean you should be able to undo the edits manually, ...
    (comp.object)
  • Re: Visual & Verbal are not as disparate as language suggests
    ... design, and layout she wanted for her book. ... but not directly for writing. ... for this communication, however is ... of your brain and adding a new perspective such as visualization can ...
    (rec.arts.sf.composition)
  • 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: OODesign - OPF, design pattern
    ... Peter Morris wrote: ... is exactly what it takes - writing wrappers and reinventing. ... Framework Oriented". ... design started as extremely elegant. ...
    (borland.public.delphi.non-technical)
  • Re: The value of a CS education
    ... being a good programmer, either. ... I wouldn't trust a CS with writing a device driver! ... career. ... design -- or a microwave transmitter, ...
    (sci.electronics.design)