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 horrendously slow.

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 at [email protected].


  • Elections
    voting security

    'Unprecedented' challenges to safe, secure 2020 vote

    Our election infrastructure is bending under the stress of multiple crises. Administrators say they are doing all they can to ensure it doesn't break.

  • FCW Perspectives
    zero trust network

    Can government get to zero trust?

    Today's hybrid infrastructures and highly mobile workforces need the protection zero trust security can provide. Too bad there are obstacles at almost every turn.

Stay Connected


Sign up for our newsletter.

I agree to this site's Privacy Policy.