When clicks go bad
As a 30-year participant in the data processing industry, every now and
then I have occasion to reflect on the quality of software. Whether software
operates in a relatively bug-free fashion has a substantial impact on government
agencies, and indeed on users everywhere.
I recently created a document on a PC using Microsoft Corp.'s Word 2000,
Visio 2000 and Windows 2000. Things seemed fine, and I e-mailed the document
to several recipients.
I got a call from one of them, asking if I could print the document
and send it to him because he "was having trouble printing it." An odd request,
but I sat down, opened the document, and clicked the "Print" icon. Next
thing I knew, I had a blue screen and my computer was rebooting.
I'm still in the middle of trying to figure this one out. It's very
reliable: Every print request to this document causes it to happen. And
each iteration results in Windows running the check disk utility, which
takes 10 minutes or longer as a large hard drive is checked for errors.
Of course, I'd like to know why this is happening. I could spend $245
on a support call to Microsoft, but I don't want to know that badly. (Support
directly from Microsoft is generally very competent, and they stick with
the problem until the end.)
There are some good resources on Microsoft's Web site that talk about
how to recover from various problems with Word documents you can save
them in another format and try to bring them back. You can save them as
text (though that would seem problematic for the Visio graphics). You can
copy all but the final paragraph mark to a new document via the clipboard.
Last year we had similar problems with a Java development environment.
The product worked fine for small problems and demonstrations. But on a
larger project, it showed its dark side. We had to write our own versions
of some of the supplied classes because certain database operations were
The worst problems, however, were crashes and lockups. It got to the
point where the lead engineer had a documented procedure for recovering
from a lockup, which included going deep into the directory structure and
manually deleting certain files.
Taken together, all those problems accounted for a significant part
of the effort on that development project.
There's a common thread here: All of these software products work fine
for demos and for simple tasks on lightly loaded computers. But when you
put them to work on a complex problem, on computers that probably have
had dozens of third- party software packages installed and (sometimes partially)
un-installed, results can be very unpredictable and time-consuming.
If you have a software development project under way, or even a large
administrative or documentation effort, build in some extra time and dollars
to deal with the instability of modern commercial software.
Bragg is an independent consultant and systems architect with extensive
experience in the federal market. He welcomes your questions and topic suggestions