Brad Appleton wrote:
> Mike Beedle wrote:
>> Reversibility and traceability are great concepts but are hard to
> Sure - at the level you are claiming is being asked for. Problem is
> that's NOT what's being asked for! It IS POSSIBLE to do
> lightweight/lean traceability. I've done it, Alistair said he's seen
> it done. And I know of many others that done it too. No one here asked
> for "perfect" traceability or "full" - just plain old "good enough"
> and "barely sufficient" traceability. Alistair described one way. I
> described another. So let's get off the "IMPOSSIBLE" kick shall we
> because its already been disproven.
I would like to see a couple of working examples to really assess
Please don't misunderstand me, I like the idea of doing:
just plain old "good enough" and
"barely sufficient" traceability.
(That's I am trying to do with Balanced Agility with Scrum, "good
and "barely sufficient" Agile Software Development ;-) But
I also think we should present the arguments as to *why*
thorough traceability and reversibility are impossible, at least
with our current tools and environments.
Perhaps a good Open Source Eclipse plug-in will do for bare-bones
traceability .... with some minimal automated "registration
system" per class? I don't know of such a thing, unfortunately.
NOTE: If most people are wondering why the "fireworks" are
going off in this thread, is because it was *precisely* this kind
of arguments about software being "traceable and reversible"
from many artifacts that fueled the movement of Agile Software
Through the 90's some proponents in the industry claimed that
their processes and tools would deliver "traceable and
reversible software" across many artifacts, but many of us at
the other side of the fence were asking:
1) at what cost?
2) with what purpose?
3) with what benefits?
That is a significant part of the "Agile soapbox",
"Writing is re-writing."