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 tbragg@acm.org.

Featured

  • Defense
    The Pentagon (Photo by Ivan Cholakov / Shutterstock)

    DOD CIO hits pause on JEDI cloud acquisition

    Dana Deasy set cloud as his office's top priority. But when it comes to the JEDI request for proposal, he's directed staff to "pause" to compile a comprehensive review.

  • Cybersecurity
    By Gorodenkoff shutterstock ID 761940757

    Waging cyber war without a rulebook

    As the U.S. looks to go on the offense in the cyber domain, critical questions remain unanswered around who will take the lead and how clearly to draw the rules of engagement.

  • Government Innovation Awards
    Government Innovation Awards - https://governmentinnovationawards.com

    Deadline extended for Rising Star nominations

    You now have until July 18 to help us identify the early-career innovators and change agents in government IT.

Stay Connected

FCW Update

Sign up for our newsletter.

I agree to this site's Privacy Policy.