TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> -----Original Message-----
> From:
> techwr-l-bounces+kevin -dot- mclauchlan=safenet-inc -dot- com -at- lists -dot- techwr
-l.com [mailto:techwr-l-bounces+kevin.mclauchlan=safenet-> inc -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Peter Neilson
> Sent: Monday, March 15, 2010 12:21 PM
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: Re: Address this. . .
>
> It's time for two more cents. I've sidestepped (ignored) a lot of the
> discussion, but ...
>
> A lot of people (I'm one) are afraid to install updates or
> new versions.
>
> "Except for the bug, the old version works just fine. Why
> don't you fix
> the bug?"
>
> --"Right. We addressed that issue. It's ok in the new
> version. Did you
> install the new version?"
>
> "No. I don't want the new version. I just want the bug fixed."
---
TWIMC - I'm no longer discussing/arguing anthing about
the original topic. I've resolved that in my work and
I've dropped it (... hey, I heard that chorus of cheers)
on the list.
This is now a separate discussion, now that the new OP
has started without starting a new thread.
---
How many other bugs were there, that also got fixed
in the new version that you fear?
How many of them should have been broken out as separate
little stand-alone releases, developed, packaged and
tested on all platforms, exhaustively (did the fix
break something else? did somebody else's fix break
our fix for your favorite bug? Did you suddenly grow
a giant bank account to finance this? We know you are
more important than everybody else, but all our hundreds
or hundreds of thousands of other customers think the
same... and not about you. Thus many (perhaps not all)
companies handle bugs and improvements as follows:
I don't know how other makers of hardware-and-software
do it, but let's look at a hypothetical ExampleCompany
that mostly doesn't do single-issue patches, to
discover why they might choose to not do one-patch releases.
If they were to employ enough resources (people, machines, etc.)
to do that for multiple problems, while also maintaining the
two or three multi-issue releases per product per year that
they do, their prices would need to go _way_ up.
Instead, if something is actually broken, they assign it
a priority, based on impact on customers.
If there's a workaround, it gets a lower priority than
if it doesn't have a workaround.
If only one or two customers out of hundreds or thousands
has even noticed, it gets a lower priority than a bug
that is widely annoying.
If it's a show-stopper it gets top priority.
Perhaps something is not broken, but (say) new customers
find it inconvenient for the things that they want
to accomplish. Or perhaps the way they want to accomplish
what previous customers have done (in a way that
ExampleCompany has historically supported).
ExampleCompany assigns _that_ a priority.
This sort of issue often comes up as Sales and Sales-Eng
are engaging new and potential customers.
If something looks like a newly-discovered security
problem, ExampleCompany assigns that a very high priority.
If something looks like it would cause their product
to address a need in a new market segment, and would
not take a major re-design to implement, then
ExampleCompany assigns it a priority.
When it comes time to specify a coming release,
ExampleCompany looks at all the open issues that
aren't already specifically assigned to some later
version, and ExampleCompany personnel order them
and beat each other up (figuratively
speaking... mostly... :-) ) until a consensus is
reached as to what can realistically be managed
this time around. It's a balance between all the
things they (and their customers) would like them
to do and drawing a line in the sand in order to
get something developed, tested, and out the door.
The mythical beast called "code freeze" is supposed
to live in that space. They say. Whoever 'they' are.
As ExampleCompany carries on business, certain
milestones are inevitable. Eventually, some old
supported platforms must be dropped off the list
to make way for more modern stuff. Similarly,
some newer platforms, while they would be nice to
have, can be delayed until ExampleCompany thinks
there's sufficient up-take by their market, before
they jump in and add them to the current
tested/supported list. Adding new ones doesn't
necessarily bump old ones, but when the old ones
are tied to very old hardware that's a strike against.
As well, some of ExampleCompany's old hardware must
eventually be declared EOL (end of life) because
they simply cannot get parts to make (or even repair)
any more.
The entire semi-conductor industry might have
moved on... and unlike the shop that will sell you
some ancient memory sticks for your ancient PC,
ExampleCompany is not allowed to employ used or
non-qualified parts. When their EOL stock - the
last batch that they built in order to have
repair/swap hardware available for old customers -
runs out, that's it.
End of support. They always announce both dates,
(EOL and EOS) loud and clear.
Anyway, with few exceptions, most bugs and other
types of "issues" get rolled into the next release
where they'll reasonably fit. If the next release
is client/software-only, then no firmware "issues"
are fixed in that release. It might be a few more
months before a new firmware release is ready - that's
because a firmware release is a much bigger deal,
affecting things at a lower level and a wider reach...
so development, debugging and testing are necessarily
more involved.
It can happen that an issue is temporarily fixed in
software until it can later be fixed in firmware...
and so ExampleCompany might have to warn customers to
please don't develop scripts and other dependencies
that will break when ExampleCompany re-engineers
with the "final" fix and takes the temporary fix
out of software.
When a bug - or even a works-as-designed - has persisted
with a workaround for some time, ExampleCompany
might need to be careful when developing a real fix
that they don't simultaneously break anything for
customers who have relied on the workaround.
If that can't be done, then ExampleCompany has to be
loud and clear that such customers should not
upgrade (no matter what other attractions are in
the newer release) until they are ready to switch
from the workaround to the fixed/repaired workflow
(or scripts or whatever).
Sometimes, the obvious, most straightforward, and
most stable fix is one that's incorporated in
firmware, but a large installed base of customers
is committed to a previous hardware/firmware combo that
has been validated to XYZ standard by some agency. They
need the fix, but they can't 'legally' update hw/fw
until the revised hw/fw combo receives validation...
which might be well over a year.
So then we ExampleCompany has to provide a
less-desirable fix in software for the time being.
The point of all this blather is to indicate - for
those who weren't aware - that it's NOWHERE NEAR as
simple as "if it's broken, just fix it!".
It's also NOWHERE NEAR as simple as "just keep adding
resources until you can support everybody". Real
life economics doesn't work that way. Programmers,
testers, platforms and test-jigs are not free, but
customers and would-be customers have a certain resistance
to runaway price increases that would pay for all
the people and infrastructure... go figure.
The techwriter gets to watch all that happen, occasionally
contribute, then sort out how the outcome affects
customers, and what those customers will need to know.
A company that can please everybody all the time is
really nice and you want to buy from them, but if
they do their people-pleasing at the expense of
controlling their costs, they'll soon be gone.
And you'll be holding a bag-of-whatever that is
no longer supported and has no future.... unless
it gets taken over by a company that DOES control
its costs... and therefore can't just say 'yes' to
every demand, every time.
- Kevin
PS: This was old-hat to many people on the list,
but it is to be hoped that the people who didn't
grasp it would have taken the time to read and
understand... or ask questions.
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
Explore CAREER options and paths related to Technical Writing,
learn to create SOFTWARE REQUIREMENTS documents, and
get tips on FUNCTIONAL SPECIFICATION best practices. Free at: http://www.ModernAnalyst.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
