Workarounds are evil.

I work in the sustaining organization. We fix bugs in released products,
generally by producing patches. A customer calls in a bug, and if the bug
is verified and we can fix it, we produce a patch.

Now, being a enterprise geared company, we hate bugs, but we fear
patches. Patches change things and cannot be tested to the same degree
that releases are. So, if we can find another solution, we do not issue
a patch. The bugs are still all fixed in the next release of the
product, since those releases goes through extensive testing as a whole,
but the already released versions are not fixed.

Since we fear patches, unless a bug is a serious data corruption or
security problem, we only patch it if a customer complains about it, on
the theory that if nobody cares enough to complain, it doesn’t hurt
enough to be worth the risk to patch. But if a customer does complain,
then there are probably other customers that have been bitten that
didn’t call, so we should fix it.

The only thing is, since we fear patches, the first thing we look for is
the availability of a workaround. A workaround is a change in procedure,
or configration or something else that will alleviate the difficulty
without actually fixing the problem. If a reasonable workaround exists,
a patch is not (cannot) be produced.

I question the wisdom of this policy. First, it almost always requires
the a customer to place a service call before a workaround is given.
This wastes time and costs money, not to mention the ill feelings for
customers that just give up and don’t call in. Of course, the patch
costs money too, so it might be a wash in that regard. But patches are
proactive. They are included in the next update release, so many
customers will have the fix before they have the problem. Others have a
simple solution when they do call in.

Plus, patches come and go, but workarounds are forever. We have ways to
track patches and add them and remove them and prevent conflicting
patches. We have no such mechanism for workarounds. Workarounds enter
the local company lore and the origins are often forgotten, but the
workarounds live on. I have seen workarounds in place on systems that
have never run an OS with the problem that they are supposed to fix.
Some workarounds have a downside that was deemed worth the cost when
they were installed, but years later, the cost is still incurred long
after the benfit is gone.


2 responses to this post.

  1. Posted by Anonymous on July 29, 2004 at 7:44 pm

    The comments you describe above are 100% of the reason my company is in the middle of moving a 100% Sun shop to 100% IBM. Thank-you for this confirmation that Sun is lazy.


  2. Posted by Brian Utterback on July 30, 2004 at 6:05 am

    No wonder you posted anonymously. If what I said is 100% the reason that your company is switching, then your company is 100% mismanaged. There is nothing in my post that has anything to do with being “lazy”. It is all about risk management and cost/benefits. Issuing patches is very risky and enterprise class customers are risk adverse. My point is that workarounds are commonly viewed as “no risk”, but the secondary effects are risky and cost money and time.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: