Bug-free dreams

YOU'VE ENCOUNTERED A bug, but where does the responsibility for it lie? Software developers say that's a question that needs an answer for software quality to really improve.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

During both our recent discussions about the need for bug-free software and the earlier topic of software maintenance programs, I've received a large number of thoughtful messages from software professionals. While very earnest in their desire to see the overall quality of software get better, they see a major stumbling block. How can we know for sure who ultimately bears the responsibility for a bug? How indeed can we be sure it even is a bug?

Take for example the problem of the bug that can't be reproduced. "Once or twice a year we receive a report from an anguished user that our software doesn't print properly," wrote one software developer. "What they know: All their other programs print fine. What we know: No one else with the same printer has ever reported a problem. We are unable to duplicate it. Whose bug is that? Ours? Printer vendor's? Windows? Are we going to investigate or fix it? For two users a year? No way. We offer to refund their money, it's cheaper. But you can bet those two people will holler like they were 200."

In a complex world, how can a software developer possibly avoid all bugs? "I don't want to sound like I'm beating a dead horse or anything, but a major problem with getting bug-free software is the multitudinous types of hardware out there," another reader wrote.

"Which motherboard with which chip set, with which graphics card, sound card, and hard drive controller, and which version and service pack of the OS, and on and on and on. With all those thousands of potential conflicts in a single box, how does a software developer make sure its software works? Is the developer community even able to figure out what standards they should be writing to remain compatible for future updates and competitor's software? [If not], one's bug fix is another's bug creation," the reader said.

Even those in businesses where software is tested thoroughly say bugs still happen. "I am a software developer in the process control industry and would like to feel that my software is adequately tested prior to release," wrote another reader. "The software developed is tested at four phases: by the development engineer, by an engineering technician, by a quality assurance engineer, and finally as a beta release. Even though there is a reasonably rigorous test procedure in place, on occasion software gets released with bugs in it. These tend to be bugs that only show themselves when the instruments are used in an unusual manner or in a manner that causes a succession of events to occur. To test for every possible usage of a system is an unfeasible goal."

Today's bug may not have been a bug when the software was designed. "A good share of our bugs come from users doing things that were hard to predict when we developed the software, and because those requesting the software had no way to accurately predict what they were going to need," wrote a developer in the telecommunications industry.

"We have to guess sometimes when we are pioneering things. It is somewhat hard to trap errors that were not thought of in advance and are rarely caught until the software is hammered on in the real world for a while. Using your car analogy, even the auto manufacturers can't stop drunk drivers from driving for example, or stop a user from running a red light and causing an accident. The only thing that they can do is try to protect the 'user' from killing himself when he does unpredictable things. The user can be controlled by limiting his options and offering 'bug-free software' which is also very limited in scope. This is not acceptable to the user, nor should it be," the developer added.

Maybe the old it's-not-a-bug-but-a-feature line is truer than we thought. "There are a number of factors that will continue, despite our best efforts, our acquaintance with buggy software," another software developer wrote. "Whether we legislate or otherwise adjudicate them into an illegality or not, the laws of man tend to pale in the face of the laws of nature. It might seem a simple thing to declare some program behavior as a bug. That notion can oft be quickly dashed by sitting in a committee judging a piece of software, or pretty much any other system. What's one man's bug is another man's feature, often enough."

OK, I think we can all agree that bugs can be hard or sometimes even impossible to pin down. But where does that leave us? A user may be wrong in thinking a particular bug is the fault of a particular developer, but the user still needs to start somewhere to find a solution. Buggy software would be much less of a problem if it didn't always (at least with the big software publishers) seem to go hand in hand with poor support, over-priced maintenance programs, and upgrades that just add new bugs to the old ones.

"I can accept the fact that some bugs will remain in commercial software, even if the company tries hard to eliminate them," one reader wrote. "What I can't accept is that a company can charge its customers extra support dollars to deal with those bugs and charge serious sums for bug fixes. In my view, it's the combination of buggy software and how the vendor deals with bugs that matters."

It's one thing to say it's not your fault, it's quite another to say you won't accept responsibility whether it's your fault or not. The latter is what too many software customers hear too often from too many software companies. So I reiterate: We may never actually see software that is truly bug-free, but that doesn't mean we shouldn't start demanding it.