3

I have submitted a bug report over a month ago to one of the biggest software companies about one of their flagship development products (I deliberately not include any more details about this bug report, so that the question doesn't turn into a rant). I only received an templated assurance that "we're working on it".

  • Is it normal for big companies to react to bug reports at such pace?
  • Can one define a "typical" reaction time?
  • Is it typically longer than the reaction time of large & actively maintained Open Source projects, or not?
  • Is there a cultural difference in the way they react?
  • For example, maybe the commercial companies try to avoid engaging in discussions about the bugs in fear of bad PR?
Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
quant_dev
  • 5,117
  • 2
  • 22
  • 26

3 Answers3

8

Everything depends on the bug and the importance of the bug.

It is not unusual for example for Microsoft to spend weeks or months solving a bug reported through Microsoft Connect. In fact, for some, they don't care about the speed, even if the bug concerns one of their lead products.

In order to be solved, the bug must be:

  • Reproduced in labs,
  • Assigned to a team of developers who must first evaluate the impact of the changes,
  • Solved,
  • Released as a fix/update.

Even the first step is long and hard to do, sometimes impossible because of the lack of information.

Now, imagine that the bug is affecting only you, and it not very important (i.e. it does not affect your work in a way that you cannot use their software at all). There are chances they will not be very motivated to spend thousands of dollars solving it, especially when they have more important bug reports which affect hundreds of thousands of users.

Michael K
  • 15,539
  • 9
  • 61
  • 93
Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • Let's give an example: what if it's a compiler bug? i.e. it doesn't compile the code which is standard-compliant and compiles in other compilers. – quant_dev Aug 01 '11 at 13:41
  • 1
    @quant_dev Are you sure the compiler is supposed to be standards-compliant? Many things deviate from the standard, and it's documented. The defect could be as simple as updating the documentation to reflect the lack of standards compliance. Just because you think it's a bug doesn't mean that it isn't intended behavior. – Thomas Owens Aug 01 '11 at 13:44
  • Again, it depends on how you formulated your bug report, how easy can it be reproduced, how many people are affected, etc. – Arseni Mourzenko Aug 01 '11 at 13:45
  • @Thomas Owens True! – quant_dev Aug 01 '11 at 13:45
2

Let's take the first bug from Top 25 Bugs in Oracle's Java bug database.

  • Submit Date: Filed 05-FEB-1998
  • State: 3-Accepted, bug

The second one is from 2008. Third is from 1997. Fourth is from 2002. And so on. This is one of the world's most popular platforms, one that runs lots of critical enterprise-level stuff.

Firefox has 493 open bugs in the toolbar category only. The fact is that all big software projects have so many bugs that most of them never get fixed. At best, they get reasonably prioritized so that the most painful bugs maybe get fixed some day. But I've never seen a major piece of software whose open bug count would decrease as time goes by.

For example, maybe the commercial companies try to avoid engaging in discussions about the bugs in fear of bad PR?

This is why popular online forums, such as StackExchange sites, are almost always run by someone else.

Joonas Pulakka
  • 23,534
  • 9
  • 64
  • 93
1

The answer to your question is implicit in the question - "one of the biggest software companies". Size presents its own problems, and the larger the establishment and existing code base the slower it is to likely to be in responding to bug reports (think the turning circle of an aircraft carrier). Also bugs that do survive various iterations of the bug fixing cycle are almost by definition likely to be more obscure, and elusive, at which point all the points mentioned by @MainMa come into play, magnified by scale effects and the need to set priorities - what priority do demonstrated bugs have in the larger picture.

Chris Walton
  • 424
  • 3
  • 9
  • 1
    @Walton - It is a well known fact. After 3 release iterations a bug turns into a feature. :-) – Ramhound Aug 01 '11 at 13:58
  • @Ramhound: very true. Two weeks ago I learned about a critical feature in one of the apps I develop that broke. Turns out it was a long-standing bug that got fixed. – Joeri Sebrechts Aug 01 '11 at 20:44