Shipping with bugs

A few years ago, Eric Sink posted the following obviously accurate statement.

The six billion people of the world can be divided into two groups:

  1. People who know why every good software company ships products with known bugs.
  2. People who don't.

Anyone who has ever worked on software, knows that shipping with bugs is part of the business. Decisions are made based on risk, customer impact, severity, and a variety of other factors. While I haven't agreed with every single decision made about a bug over my career, I understand the trade offs and business justifications. Many people outside of the software industry have a hard time understanding why a company would ship software with known bugs, but I think that's a valid concern for those people. They aren't familiar enough with software engineering to understand the variety of factors that go into choosing to ship software with a known bug.

However, I still run across people who actually work with software who fall in category 2 above. For example...every testing mailing list I have ever been on, at some point, falls into a discussion revolving on bugs latent in a shipping product. Questions like "how could company X ship knowing about that bug", or "how could company Y knowingly break backward compatibility?" get asked and echoed. I suppose it's the nature of the discussion group, but to me, being able to take a step back and see the big picture in any situation is a necessity for growth beyond the rudimentary stages of any profession.

Just today, I was reading a discussion, and someone was complaining that a very old file format wasn't supported by a particular application anymore, and that that it was practically an unforgivable quality travesty. Of course, the support for the old file format was known for being a rats nest of security vulnerabilities, and had not been maintained in years. It would, in fact, have resulted in a much buggier product to have included support for the obsolete file format...but that part of the argument was ignored.

My first reaction was annoyance. I didn't understand how the person complaining could not see the big picture, but as I thought about it, I realized that quality is practically an impossible challenge, and gets harder the larger the product and customer base get. Creating software for masses of users is a big game of risk and compromise - satisfy the most people, and piss off the least. It's a tough game to play, and someday, I believe, someone will figure out how to win.

Comments (2)
  1. As a tester, most often, I battle with that dilemma – whether it’s ok to ship with this bug or not. Some decisions are really easy, but there are a few that are on the fence – stuff which might cause problems in later versions or in scenarios I didn’t dream of. And those are the bugs that are really scary – I dunno what to do with those! Agreed there is a triage bar, review process, war room etc. but it just feels so eerie when you have to make that decision.

Comments are closed.

Skip to main content