A Bug is a Bug is a Product Defect!
by Martin H. Tillinger

Visual Basic has the features to handle mission critical corporate computing needs. However, it will not be ready to handle these tasks until there is a major change in attitude for both Microsoft and developers. The basic problem is that neither party calls a bug a bug nor expects a fix.

On the developer side are attitudes shown in the statement "The product only gets GPFs if I give it bad commands." C'mon! Unless you attack the product's executable with a hex editor, it should not get GPFs. Another is found in articles in this journal describing elaborate work-arounds, but never noting that there is a product defect. Since software is written by humans, software will contain errors. Nobody is perfect and testing can only find (some) errors, not prove that there are none. The first step is to recognize errors. This starts with the user of Visual Basic - the developer. Many who have come to PCs and Visual Basic from the mainframe world of MVS have high expectations. However, many who grew up with PCs often are so happy the system does great things when it works, that they do not expect perfection.

Once the Visual Basic user recognizes a bug, the next step is to get Microsoft to recognize it. Lots of luck. The support organization, as seen on CompuServe, is hard-working, dedicated, and understaffed. However, the organization is tuned to providing bypasses and tutorials, not to documenting problems. Microsoft does not even try to answer all questions. Until I gave up, I tried to get bugs at least acknowledged and entered into the Microsoft Knowledge Base (MSKB). There seems to be no incentive for the support staff to get bugs into MSKB. There are only 561 entries in the January MSKB for Visual Basic, 160 use the word Bug in the text and only 104 use the B word in the title. Once a bug does get entered, the information provided is minimal. Usually there is information on how to reproduce and maybe a general release level. But there is no information as to which module at which level contains the defect. Many of the so-called "fixes" are merely bypasses. Bypasses are great, but are not a substitute for fixes. And a solution of "This will be fixed in the new release", does nothing for my users. Are they going to wait twelve to eighteen months? There are some fixed modules on CompuServe and even a Drivers and Patches CD as part of TechNet. Wonderful, but how do you find out which of these fixes you need and what bugs they fix? A further problem is that there is no feedback loop when problems are reported (at least on CIS).

Also prevalent is the idea that "... well, it's not a real bug." That, along with "This is the first we have heard of this problem" I get from other vendors' support representatives all the time. I even get that from my own developers. As a vendor, my policy is that if the user says it's a bug, it's a bug. We did not meet their expectations. Maybe the defect is in our advertising or product description, but they are unhappy. My company has a product that pretty prints Visual Basic programs. If you give it a program in another language, it is OK for us to print the tokens according to Visual Basic rules, but it is a bug if we get a GPF, a subscript error, overflow,or other error. Why - because someone could give us imperfect Visual Basic code to print with that sequence of characters in it. Our software certainly has bugs, and as long as people write code, there will be bugs. What we can do is to try to minimize them, detect them, and fix them.

I admit to mainframe prejudices. This means (to me) a professional attitude towards product defects. The following is typically done by mainframe software companies (like IBM): 1 - The user reports a possible problem. If it is not recognized as a known problem, it is assigned a publicly know number and description of the symptoms. There is a standard way of describing symptoms (one word for hangs/freezes/stops, etc.) 2 - When/if a bypass if found, that is added to the report. 3 - When the defective component is identified, this is added to the report. At this time, the problem description may be enlarged. 4- A fix is prepared. This may be distributed as a "zap" or patch to a module or complete replacement. These are also numbered. 5- When the next release is distributed, information is provided as to which problem numbers are corrected, which fix numbers are included and which known problems are still outstanding.

Microsoft needs to make a commitment to product support including effective procedures for bug report, tracking and resolution. Developers need to be able to obtain current information and fixes. This is key if Visual Basic is going to increase its standing as a mission critical development environment with corporate users.