Re: A replacement for "implementation"

["Huber, Mike" <mrhuber -at- SOFTWARE -dot- ROCKWELL -dot- COM>]

> From: John Gilger [mailto:JohnG -at- MIKOHN -dot- COM]
...
> "current implementation" is a weasel phrase that adds no
> information to the
> sentence. After all you are documenting the latest and
> greatest release of
> your product (unless you are a historian). Does this product have any
> "uncertain limitations"?

Not where I work. The software that we release is always a compromise
between what we hope it will be someday and what we can get done (and done
right - a serious bug or even an insufficiently tested area trumps a release
date no matter what) with limited resources in a reasonable length of time.
Marketing would like to release instantly, engineering would like to keep
working on it until that one last item is ready (i.e. forever). None of us
is ever quite happy with the results, and the phrase "current
implementation" reflects our realistic hope that the next version will
include features that we didn't have time to do in this version.

"Current implementation" also gives information. When I write that "Frammitz
does not support blofling" it means something different than when I write
that "the current implementation of Frammitz does not support blofling." The
second implies that there may be plans to support blofling in the future, or
at least that no decision has been made.

I very rarely use "current implementation" in user documentation. The
implication of a future plan is something that I try to avoid. I am much
more likely to write "Version 29.01 of Frammitz does not support blofling,"
because that is the kind of specific, testable information I prefer. And
because our manuals here are not tied to specific versions of the software.

---
Office:
mike -dot- huber -at- software -dot- rockwell -dot- com
Home:
nax -at- execpc -dot- com

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=