It's still a *bug*, and your denial does not change that

UGH!! I've had this frustrating discussion with a developer recently that is really annoying the heck out of me.

In the particular scenario being discussed, this product has a history of not installing correctly. It's a (mostly) .NET desktop suite of programs with a central processing engine. The most common installation errors involve components not registering correctly. The crazy thing about that type of issue is that it manifests itself, for this particular product at least, in fairly inconsistent ways. Sometimes, a user function doesn't work (while sometimes it does!). Sometime, the processing engine locks up unexpectedly.

In the past 4 months, I am certain that I have seen the number wasted man-hours troubleshooting something that ended up being an installation problem climb well into the hundreds. In QA alone, I can cont at least a week, times 3 people. I'm already at 120 -- not counting support, developers, product management ....

There was a customer issue that they had spent the past 2 weeks troubleshooting, only to find out that a file had not been registered properly. So product management asked the developer the following:

Is there an identifiable bug in the installation code that we could track in Bugzilla for inclusion in a future release? Or is this issue a one-off?

And the developer's response was that there was no bug in the installation code, so there was nothing to fix. He went on to explain that the files has just not registered properly or were corrupt. He said that uninstalling the suite should have cleared the problem. (I don't want to copy his response, just because it's fairly product-specific.)

So this was my response to that (I was actually fairly nice in it, because seriously, it drove me *crazy* to see that "it's not a bug" statement!)

Though I can see where there is not a clear bug in the installer, I don’t think that is the same as “we are missing something and should implement some checks”.

It just really seems to me that *any* install that we do should be checking itself, that it installed correctly. I have seen dozens of man-hours wasted in just 4 months, on what came down to things not installed properly.

“It didn’t tell me that it didn’t go right” is a bug, in my book.

Now seriously, let's look at this issue.

If the software does not install properly, that's a bug, right?

If the software fails to install properly, AND does not indicate to the user that *anything* has gone wrong, that's a bug, right?

If this install problem causes the software to not work, that's a bug, right?

Is it considered okay to ask the customer to uninstall and reinstall their product (no trivial task, mind you) when it's not working? Okay, anybody but Microsoft?

Has 10 years of testing led me way far astray from the basics? Am I way off base here?

Lanette Creamer suggested that the developer was right; that it wasn't a "code bug", but rather a requirements failure. This is a valid point, but for some reason, I hate having to "frame" things in a certain way to placate a defensive person.

The bottom line is that this product is doing something it should not be doing, and it is impacting the customers, the developers, the support people, the QA people, the product people ... IT SHOULD BE FIXED. Seriously, don't throw blame, don't deflect attention away from yourself.

Let's instead sit down together and figure out where the problem is and how to solve it.