I have a funny feeling that the nontechnical people on my current project would be nodding their heads along to the article, but the truth is that our applications have bugs that 100% of our customers are running into; they simply aren't immediately noticeable to a layperson. That doesn't mean they're not important. The business relies on complying with the rules of third-party organizations and the software is blatantly violating those rules right now. The clients are aware but still choose to prioritize new features over fixing the bugs that are creating these compliance issues. If we're caught out by those third parties before the bugs are fixed, there's a good chance it could sink the whole company. But our users don't "see" these bugs so they're not considered a priority over new products, new features, or anything else marketing might want.<p>I looked up Pinedo's background and she's not a developer; she's a social media manager. This is kind of what I figured because her perspective on development seemed really out of whack to me. There are many kinds of bugs that can't be measured with a simple stability calculation, and IME there are definitely error states that are worse than death (crashes). Plus 97% of teams are definitely not following agile principles. Every dev team I've ever been on said it was agile, and most of them just meant that there was a kanban board and something that vaguely approximated a sprint.
Something about this rubbed me the wrong way and I realized it was because this pretends that ignoring much of the long tail of userbase is not only okay but beneficial to the majority. If, say, Quip ignored bugs in IE6 that's likely fine because my parents using their CRT iMac aren't going to be using Quip, but imagine if a crucial app like Gmail ignored older browsers; suddenly all the disadvantaged people that can't afford new laptops lose access to their email.<p>If it's a bug that 10 users are hitting because they were migrated from an earlier version incorrectly, sure it might be okay not to fix, but if 10 users are hitting it because they're legally blind and using an extraordinarily large font to use your product, it's crappy to say they don't deserve a fix. You have to understand what part of your userbase is hitting a bug and then decide from there.
> There’s no such thing as a bug free application<p>This is a stretch. Seems like many people think of code as a living thing that just does what it wants, and us programmers have to beat it into submission.<p>The truth is, there can be bug free applications.<p>The problem I think is the complete opposite of the point of the article. Programmers need time to write good software. Without stopping to fix the things we run into, technical debt does what it's known for, and exponentially increases, and kills time that could be spent writing features.<p>So maybe software is like a living being in a way, that it needs to be cared for gently.
Good article. It reminds me of Sandi Metz's treatment of well-designed code as a business proposition: the goal is to save money, because a good design makes changes cheaper.<p>It makes sense to consider the cost of having a given bug vs the cost of fixing it. Of course, such estimates will almost always be hand-wavey.<p>I would also say that when in doubt, fix it. A bug is, by definition, the software not doing what it's expected to do; I think it's better to make fewer promises and keep them. A user who encounters a bug loses trust in the software, and there's a tipping point where they abandon it. You might not know where that is.<p>You also might not realize what a bad day it could give someone, even if they're only one person. Eg, if you're an email platform and you have a bug that drops one email in a million, that might seem OK. But if missing that email gets someone evicted...
"97% of respondents said they practice agile in their organization"<p>Yeah, they all <i>SAY</i> they practice agile, but a lot of them practice waterfall with agile naming conventions.
The problem is that many organizations don't know how to tell important bugs from non-important ones, don't have proper processes for bugs reported by customers, and generally ignore customers. Here's a couple of popular apps that I have used and the reason I have quit or will quit them: Hulu with the TV package constantly tells me I'm streaming to more than 2 TVs and won't play anything even though I'm not streaming to any. Youtube TV constantly plays the wrong thing when I click something to play. These are egregious bugs that I'm sure I'm not the only one experiencing because they happen on multiple, different mobile devices, tablets, the web apps, etc. The strategy outlined in the article may be viable when customers are not paying anything, but when companies charge an arm and a leg for software (> $40 / month) users expect the software to not have any major bugs like this that prevent its basic functioning. With the type of support offered by such companies, users will be moving on quickly to competitors that hopefully have their basics worked out. I wouldn't use an email program that can't send or receive email and these bugs are on par with that.
>at a certain point, it’s too expensive to keep fixing bugs because of the high-opportunity cost of building new features.<p>While I may agree with this in the abstract, in practice most folks don't really know whether they're at that point. It also doesn't consider cumulative effects over time.<p>Bugs don't just affect application stability or user experience. A system that does not behave as designed/documented/expected is a system that will be more difficult to reason about and more difficult to safely change. This incidental complexity directly increases the cost of building new features in ways difficult to measure. Further, new features implemented by hacking around unfixed flaws will themselves be more difficult to reason about and more difficult to change, exacerbating the problem.<p>The larger the system grows over time, the more people working on it over time, the faster this incidental complexity problem grows over time. At a certain point, it's too expensive to not fix the bugs because of the increasingly high cost of building new features. At that point, folks start clamouring for a rewrite, and the cycle begins anew.
The most important thing I take away from this, is that even if you don't fix the bugs, you should be aware of them and tracking them.<p>Maybe it is a bug that only affects 1 out of every 10,000 customers. But if you get enough of those it can start to add up. Keeping track of them allows you to go to management with the data to support spending a sprint on bugfixes and code maintenance.
This doesn't mention that crashes aren't the only kind of bugs. In fact, crashes are the bugs I fear least because I know about them immediately. It's the bugs that happily do the wrong thing that worry me. Like sending email to the wrong person, for example. I review email-sending code 3 times more closely than other code.
The author of this article seems to think that occurrence frequency is the sole metric of whether a bug should be fixed.<p>Which of these two is more important?<p><pre><code> - 0.1% of my users lose their data irrecoverably
- 30% of my users get an error page and have to refresh
</code></pre>
The article never waded into this at all, which is disappointing. I don't feel like I learned anything.
This article is strictly true - there are bugs that are not worth fixing. But the process of figuring out which ones are and aren't isn't as simple as crashes/sessions.<p>There are some categories of bugs that must always be fixed, regardless of how infrequently users run into them - security, privacy, accessibility, data loss.<p>There are also cases where many low impact bugs all share a common root cause - the value of fixing any one bug is low, but the sum of fixing all current and preventing all future occurrences is high value. Enforced static analysis tools (like error prone for Java) and libraries/frameworks with safety checks (autoescaping template languages, polyfills, etc) are a great way to address these long tail bugs. I generally write a new compiler error after encountering the same bug class three times.
Both parts of the title are correct:<p>* Not all are worth fixing, that is, the (financial) upside of their being fixed is too low compared to the effort required.<p>* And it's okay, that is, it's something we have to accept and live on, though it's not really nice and satisfying.
Thanks Kristine for the link to my article...<p>Myth of Five Nines - why high availability is overrated
<a href="https://www.iheavy.com/2012/04/01/the-myth-of-five-nines-why-high-availability-is-overrated/" rel="nofollow">https://www.iheavy.com/2012/04/01/the-myth-of-five-nines-why...</a>
Dijkstra raised the distinction between pleasantness and correctness. Since most programs are unspecified there is no logical grounds for declaring their behavior incorrect. Unpleasant behavior abounds however, but if your users are willing or forced to accept that unpleasantness then it can be rational to let it stand.
I don't see any mention of security or legal concerns. Not all bugs can be identified by exceptions, exception frequency is not an indication of their impact, and in some cases stability is less important then correctness. Using bugs per session as the (only?) metric is a horrible way of doing product management.
Bugs shouldn't happen. Actually, in some critical systems, bugs <i>can't</i> happen.<p>Bugs aren't magic; they happen for a reason. It could be a broken dependency(unsupported versions, fatal bug in a dependency, deprecation, configuration etc.), resource limitation(out of memory, security breach etc.), poor design which leads to poor implementation(logical errors, bad data abstractions).<p>Abstractly waving your hands and saying "we can't fix all bugs" doesn't feel right. Identify the underlying cause of the bugs and address that.<p>One solution is to reduce dependencies, increase resource allocation, and rely on a less rigid design. As a business grows, dependencies will increase, resource allocation will increase and the design will become more complex.