When Bad Bugs Happen to Good Software
[ Back ]   [ More News ]   [ Home ]
When Bad Bugs Happen to Good Software

By Bruce Pilgrim

OK, here’s the deal: Let’s say you buy a tool – no, wait – technically, you can only buy a license to use the tool, for thousands of dollars. And, if you want another person at your company to also use this tool, you can most certainly do so. At an additional charge.

Unfortunately, the tool is somewhat arcane and difficult to learn and use. Here's the good news: Your tool supplier will provide you with plenty of training. At an additional charge.

And rest assured that if you ever have questions about using the tool, you are more than welcome to call your supplier for answers. At an additional charge.

Now, because there are some things wrong with this tool, your supplier will, at irregular intervals, provide you with "updated" (i.e., fixed) versions of the tool. At an additional charge.

The updated version will not only fix some of the things that were wrong, it will also contain a bunch of new things that weren’t in the tool before. Of course, some of the things that didn’t work in the last version will continue to not work in the new version.

This is the CAD software business model.

How do CAD vendors get away with this? First, they give the software away for free, as "trial" versions. If all goes well, prospective customers will get accustomed to it (sort of), maybe find some use for it, and, ideally, become enamored with it. Then the vendor swoops in and closes the deal.

The CAD industry borrowed this strategy from drug dealers.

The "things that don’t work" referred to above are known as "bugs." And, while "bug-free" or perfect software is a nice idea, it isn’t likely anytime soon. Because software code is written by humans, bugs are inevitable. No matter how brilliant, talented, dedicated and hard-working programmers might be, and no matter how well-planned, how well-executed, and how well de-bugged any piece of code might be, bugs will happen.

CAD vendors have a number of ways to address the bug problem, including providing “workarounds” to mitigate a bug's impact. Workarounds are little instructions such as “Hold down the Alt key while humming the theme for "A Summer Place" and then press CTRL/Shift. Then Reboot. Then Repeat.” No one knows if these workarounds actually, well, work, because most people give up after trying them a couple of times.

Another strategy is denial. A customer might say, “I would like to be able to define a series of constraints, or values, to drive my design.” If the vendor's software doesn’t work very well with such an approach, the vendor will argue that using constraints is a bad idea. “Our software, by contrast, doesn’t tie you down that way, giving you the freedom to design any way you want.” (Except for that one way that you like.)

What if a customer complains that an odd thing happens during a specific activity? The fix is simple. The vendor recommends avoiding that activity at all times. It’s like the patient who tells the doctor: “It hurts when I do this.” The doctor's advice? “Don’t do that.”

If all else fails, vendors will, eventually, try to address some bugs – especially once their competitors make those bugs an issue in sales situations. If enough customers complain, or if a really important high-paying customer threatens legal action, vendors will actually kill a bug, or at least render it harmless and unnoticeable.

There are several types of bugs, ranging from the trivial to the serious to the nightmare scenarios. Category 1 bugs are odd and somewhat annoying little gnats that are fairly easy to ignore. Category 2 bugs are more like mosquitoes, bees, or hornets – they might just bite you. Category 3 bugs are great big hairy things that can send users screaming into the night.

You can count on Category 3 bugs getting fixed pretty soon, especially once the software company’s lawyers hear out about them. To avoid ever meeting the great big hairy things, it is always a good strategy to wait until at least release 1.1 before you start using a new piece of CAD software.

For marketing reasons, a majority of a vendor's R&D resources are devoted to developing new features, instead of fixing bugs that have been broken for years. That’s why the new release of your CAD system might include a nail gun, pinking shears, and a 50 foot garden hose.

This is because CAD vendors are always trying to one-up their competitors. So, if the new Acme CAD system comes with a built-in 50 caliber machine gun, then the Brand X CAD R&D team must answer with a howitzer. Before you know it, every CAD vendor is a member of the nuclear club. Meanwhile, all their customers want to do is design an electric razor.

How much resource should a software company devote to fixing bugs versus developing new features? If you ask users, most would allocate at least 99% of resources on bug extermination. However, you can't make much money just fixing bugs. How many times have you seen an ad that says: “Release 9.0: Nothing much new here, but we fixed a boatload of bugs”?

How do bugs get discovered, you ask? Well, in a perfect world, vendors would find every bug and eliminate them before they are “released” into the environment. We, however, live in a somewhat imperfect world. Software engineers really do try to debug their code and test it, using what they believe are real world scenarios. Unfortunately, most of these engineers have only seen the real world on television, so they consciously or unconsciously devise scenarios that are slam dunks for the software. This, at least, has the effect of making the engineers’ supervisors feel good.

The release of exceptionally buggy software can cause even the most docile customers to consider defecting to the competition. To forestall such unpleasantness, vendors subject a new release to beta testing. In beta testing, vendors often try to trick customers into testing unreleased software and finding the bugs for them. Of course, the customers are on to this and won't fall for it. They agree to help anyway, however, with their eyes wide open, figuring if they find the bugs now, they won’t get bitten by them later.

When the new release comes out, you can be assured that, A. The software will consume a lot more memory on your computer, and B. Some of the things you really liked that didn’t need fixing will have been changed, I mean, improved, in new and very annoying ways. These are called enhancements.

Enhancements are usually previewed at users' conferences. To relieve the boredom of these events, and to distract users from the inevitably bad news that is to come, planners make sure these events provide many different types of entertainment.

First, there are the demographics of the gathering itself: We’re talking legions of math club types, 99% of whom are male, 0% of whom ever seriously dreamt of pursuing careers as underwear models. Just watching them is pretty entertaining. Then, there are the conference speakers, who mercilessly abuse their audiences with PowerPoint. When such sessions finally end, the audience responds with grateful applause.

But nothing is quite as entertaining as the skits performed by the software company. Popular movies are often “spoofed” as a way of introducing demonstrations of new software functionality. This is even less enthralling than it sounds. The ineptitude of these performances is only exceeded by the crowd’s enthusiastic approval. They are so desperate for entertainment, their standards are at the lowest possible ebb.

That’s when the vender tells them that the next release will be delayed, maintenance fees are going to increase, and the new features they were counting on won’t be ready when promised. Such announcements are made late in the conference when users are usually too numb to react.

And there is the biggest news of all. "You know that new capability that was added in the previous release?" asks the vendor. "We, or rather you, have finally debugged it. And now that it works, we have decided to “unbundle” it. Unbundling means that the new capability is now a separate module available for purchase.

At an additional charge.

By, Bruce Pilgrim

For more discussions, follow this link …