Phlip wrote:
> adaworks wrote:
>>Agile methods may be OK for some projects, but there are still a great
> many
>>applications for which it is inappropriate and sometimes, dangerous.
> Which practice is dangerous?
> - the most qualified customer representative works 40 hours a week
> on the project
> - the ability to safely change code is scrupulously maintained, even
> if the code won't change
> - pairs write all code
> - pairs rotate frequently and ensure they understand all modules
> - nobody works too late
> - pairs delete code not required by tests
> - the customer writes the high-level tests
> - all tests must pass before checking in
> - everyone works on the same codebase
> - nobody changes anything with returning to a releasable
> state as frequently as possible - many times an hour
> If you mean "oh, Big Design Up Front might possibly detect the need to
> prevent our software from killing people", I think I'd rather go with design
> changes made in the presence of aggressive tests.
Phlip,
I am afraid you really do come across as someone who only has one tool
in their toolbox, a hammer, and to whom every problem therefore looks
like a nail. There are indeed some sound practices in the extreme and
agile movements, mostly the ones that they have lifted from the body of
previous good experience like frequent and rapid regression testing;
however, this doesn't mean that rigorous, mindless application of these
guidelines, as you certainly come over as advocating, is appropriate in
all situations.
Let's test some of your "rules" listed above against something I know a
little bit about: an aircraft weapon systems. OK, so we collect some
stories and scenarios. One says "when you press this button, a bomb
falls of the aircraft". One of your pairs can write a test for that and
write code that passes that test. Trivially easy - after all how much
code do you need to connect a button to a release unit? However,
another requirement says "A bomb mustn't fall off the aeroplane in 10**9
hours if the button isn't pressed (that 114,000 years by the way). Now
that is rather more difficult to write a test for, but it does
fundamentally drive the way in which the bomb release code must be
written. We will have to introduce things like multiple computation
paths, baton passing and dynamic "magic number" generation to ensure
that the weapon release code can only be activated by the planned route.
These properties are called "design" and cannot possibly emerge from a
feature-by-feature implementation.
So let's say we get past that hurdle, and also the well-documented and
well-proven obstacle that no amount of testing is sufficient to
demonstrate properties in the 10**9 area we need for this application.
Now along comes another requirement of weapon systems. The same system
that must have a very LOW probability of inadvertent weapon release has
to have a very HIGH probability of successful jettison on demand
(jettison is just like release except the bomb isn't armed). Surprise
surprise the typical requirement is that jettison should only fail once
in 10**9 demands. Meeting these nearly opposite requirements needs some
fancy DESIGN. e.g. dual channels that must AND for release but are
allowed to OR for jettison. Again it is completely infeasible that
precise, hard, non-functional properties such as this can "emerge" from
a test-driven, hack-as-you-go design process.
And no, I am not advocating the impossible creed of knowing every
requirement and finalizing every detail of design before you start. As
that strange Rumsfeld man said "there are known unknowns and unknown
unknowns"; so you do have to do enough requirements capture to know what
you know and enough design to protect you from the remaining
uncertainties. Thereafter, some of the XP/Agile practices may be
helpful (as may some of the OO ones) but they are not a religion as you
seem so keen to present them.
regards
Peter
