18

It seems that frequently in large projects the software is still released with the bug tracker full of bugs. Now I can understand feature requests, but several times I've seen large numbers of bugs still unresolved, not reviewed, or not finished but a release is still pushed out.

Why? Why would an open source project or a project in general be released with known bugs? Why wouldn't they wait until the bug tracker had 0 opened bugs?

Improve this question
15
  • 3
    Smells like a dupe.
    – Job
    Oct 3, 2011 at 16:53
  • 41
    Show us some usable software without bugs.
    – Joel Etherton
    Oct 3, 2011 at 17:04
  • 13
    Because while time is infinite, people aren't?
    – Joe
    Oct 3, 2011 at 17:09
  • 7
    Thanks for this post, it gave me a good laugh... I wasn't surprised to see you're 18 in your profile. :D You obviously haven't worked with software team managers yet.
    – Yam Marcovic
    Oct 3, 2011 at 17:41
  • 7
    One of the more common reasons: The release fixes critical bugs or bugs that are impacting real-world customers and, at least as far as is known, doesn't add any new bugs that are likely to do so.
    – David Schwartz
    Oct 3, 2011 at 18:30

10 Answers 10

Reset to default
41

Any number of reasons, including:

  1. Company had made commitment to user base to release at a particular time
  2. Bugs were not mission-critical, or even major
  3. New feature development was viewed as more important (whether correctly or not)

To a small extent, this is like asking why you work as a programmer even though your programming knowledge isn't "complete". In most complex projects, there will be many, many bugs. Dealing with them while adding new features is a difficult, complex task.

Improve this answer
3
  • 24
    +1, but I want to add: 4) Bizarre unrepeatable seemingly one-time occurrence bugs that QA logs. These kinds of things should be tracked but may have been the result of an inexplicable network outage, unplanned environment downtime, or QA just simply didn't provide enough information for it to be possibly debugged. 5) Minor bugs that take a disproportianate amount of effort to resolve, Eg. Complete refactor of a specific module.
    – maple_shaft ♦
    Oct 3, 2011 at 17:10
  • 4
    Good comment, the minor bugs that require gargantuan refactoring efforts to eliminate tend to go unaddressed.
    – eykanal
    Oct 3, 2011 at 17:12
  • 5
    Could also be that bugs were not seen by the company as mission critical or major. Clients may say otherwise, but you only know when your clients tell you.
    – joshin4colours
    Oct 3, 2011 at 17:15
38

Because a software with a bug is better than no software at all.
For the same reason:

  • Transportation companies bother making schedules, even though there's always delay.
  • Pharmaceutical companies sell medication with known (and mostly documented) side-effects.
  • Schools all over the world teach Newtonian physics, although it has known limitations.

Having a solution with known deficiencies is much better than having no solution, or having a solution with unknown deficiencies.
My favourite IDE has a lot of fresh features, that are far from stable. Let's just say: I prefer, having to do something by hand every twentieth time, because the feature fails, rather than having to do it all by hand.

Or to say it with the words of Voltaire: "Le mieux est l'ennemi du bien."

Improve this answer
0
22

Ultimately, it's a business decision, even for free and open source software. There's a point where the defects that exist are of a low impact that it's better to release, get your software into the hands of the user, and get feedback (including, but not limited to, feature requests and new bug reports of defects not found in testing). This decision is driven by the need to get traction in the market for the software among competitors. If you want your software to make an impact, you need to beat your competitors to market with new features or concepts.

Improve this answer
1
  • 1
    I would note that obviously if your software is full of bugs, the impact made may not be beneficial ;)
    – Matthieu M.
    Oct 3, 2011 at 18:01
7

everything boils down to cost vs. benefit analysis. Each bug fix has some cost value associated with it (man hours to fix, risk of making more code changes X days before release...). At the same time, each bug fix clearly brings additional value in terms of more features, usability, etc.

So this the question every development team faces when making a release: 1) is Bug #i is worth fixing given the cost and additional value and 2) repeat for all open bugs from i = 0 to N.

Keep in mind that a software product that is not released has NO value to anyone. Software product that has 200 outstanding bugs but has 90% of its functionality working, has value to all the people who are happy with what works at the time of the release.

I've never in any company on any product that was released with 0 bugs and I think that's perfectly normal. At some point, you just cut your losses and capitalize on what works. Otherwise, you'll never release anything.

Improve this answer
6

In a large project, you never stop finding bugs. If you had to wait until all bugs were fixed and the fixes regression tested, you would never release.

Also, note that not all bugs are internal. Every program is part of a complex web of other software, and changes elsewhere can manifest themselves as "bugs" in your software. You can't stop the world.

Improve this answer
1
  • Related to this is the fact that every bug fix creates the opportunity to introduce new bugs in the product which can be more serious than the original bug.
    – Malachi
    Oct 3, 2011 at 18:41
4

In addition to the many good answers, sometimes there is a race to market with a new product. If you think you can gain the majority of market share even with 15% (or some other number) of non-critical defects open, it might be worth releasing the product to get an edge on the competitors.

Improve this answer
2

These bugs may be pretty minor. Remember that commercial software needs to be shipped, and pressed on discs, and such things. Meeting those release dates has serious financial implications, and delaying for some minor issues is not financial sense- not to mention the need to get to market for other reasons.

Improve this answer
2

Potential answers:

  • It is highly unlikely for anyone to encounter the bug.
  • There are workarounds for the bugs.
  • The software needs to be released sometime, and perfection is unlikely to be achieved.
Improve this answer
2

I'm sure ideally most developers would like to see zero bugs in their applications, sadly conditions may not allow for such a state of utopia.

I would like to believe it's because the user base demands new features and are willing to take onboard the same or more bugs for added functionality.

If there's management involved, deadlines need to be met for a range of reasons - advertising schedules, additional staff availability issues, the "we-must-be-the-first-with-this-functionality" mindset.

Less optimistic in my mind, possibly because the developers are lazy?

Also remember that in open-source communities it's typically "whom" wants to take on what bug/feature/issue requests - perhaps no one wishes to deal with the problems that are present due to larger issues behind them.

Improve this answer
1

In the simplest programmatic test:

if (management->perceived_cost_to_fix > management->perceived_benefit_release_now) {
    release;
}

Everything is always a trade-off, whether it be fixing bugs, time / space / memory, or security / usability. Think about the tradeoff calculation that was done. You may disagree with it, but you're in trouble if you don't understand it.

Also, think about those calculations in a bell curve... some people will make really bad ones to either side. See Duke Nukem Forever for one end of the curve.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.