Re: Rapid Application Development

Ben C wrote:

I'm not sure about this. In programming you have to "be slow to be
fast".

The book /Rapid Application Development/ has a nice chart in the middle. It
shows a "low visibility project" going very fast, but under dark shadows.
Such a project is not visible to a customer liaison. They don't know what
they will get until the team stops.

Then it shows a high visibility project, going slower. This project has to
stop frequently to work on the "visibility" feature. If a project practiced
Frequent Releases, for example, then every other Friday could be "release
day", when everyone firms up their changes, creates a release candidate,
tests it, and documents it.

The book also gives naught but lip-service to automated tests.

Taking a bit of extra time to document as you go along may speed
up development measured over the next year or so because the act of
documenting has slowed people down a bit and made them think more about
what they're doing-- so fewer bugs to fix, and clearer code so they're
easier to fix.

Replace "document" with "write test cases" in the above paragraph, and you
have documentation that prevents bugs and helps you go fast. You don't "take
time to write test cases".

And because your customer liaison participates in the testing, the test
cases _also_ push up visibility.

All as a by-product of reducing waste and debugging. Not in despite of them.

Here are two examples of literate tests working as documentation:

http://www.zeroplayer.com/cgi-bin/wiki?TestFlea (click a green bar)
http://fitnesse.org/FitNesse.SuiteAcceptanceTests (might be down!)

To answer Richard Heathfield, and Fred Brooks, tests can become the primary
conduit for team conversations...

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


.