8 ms·

Not all bugs are worth fixing and that's okay

87 points by kinbiko 8y ago

larrik 8y ago
"97% of respondents said they practice agile in their organization" Yeah, they all SAY they practice agile, but a lot of them practice waterfall with agile naming conventions.
- scaryclam 8y ago
  Or they practice not having any process and say it's agile because they constantly context switch...
- betadreamer 8y ago
  100%. They think they are doing agile as long as they have Sprints. Startup I'm working at right now told me "Agile" is overkill for us. But ironically it's more iterative then any company I worked before that did sprints.
  - joombaga 8y ago
    > "Agile" is overkill for us. What does this mean/did they mean by this?
    - betadreamer 8y ago
      yeah being agile is good. I meant by incorporating Agile frameworks like Scrum.
  - nottorp 8y ago
    Every competent programmer that I know did a form of agile (just the sane parts) long before Agile was a religion.
- ken 8y ago
  This number sounded suspicious to me, so I downloaded the report. What it actually says is that 97% of organizations practice some level of agile, but the percentage of teams using agile is much lower. The most common response (46%) was "Less than 1/2 of our teams are agile", for example. Saying that "97% of organizations practice agile development methods" makes it sound like it's overwhelmingly dominant, but it's not even possible to tell from these responses if a plurality of the teams who responded to a "State of Agile survey" use it, or what the most common development methodology is. This is exactly the sort of contextless figure that you'll find torn apart in "How to Lie with Statistics". > "JavaScript is more popular than ever, and over 69% of developers use JavaScript Does anyone really believe that StackOverflow surveys gather a representative sample of all developers? This same survey found that 1 in 6 developers target the Raspberry Pi (more than iOS), and 7.5% use assembly language (more than Go, Objective-C, or VB.NET). It's an interesting survey but take it with a grain of salt.
deleted 8y ago
[deleted]
nowayjose2 8y ago
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. 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.
- _r_o_y_ 8y ago
  It's not exactly related to your post but remember that Agile != Sprints
  - qznc 8y ago
    That is like Open Source != FOSS, a lost cause.
    - matthewmacleod 8y ago
      No, it’s not. That kind of atfitude is pervasive and wrong. Loads of teams are nowhere near Scrum and work basically Kanban. That’s reasonably agile.
  - nowayjose2 8y ago
    I know, but that doesn't stop managers from claiming that any process on some kind of n-week cycle is "agile". Maybe I've had bad luck, but it feels like a lot of companies pick up some agile-for-managers book and implement whichever process is there, minus the parts of the process that make them uncomfortable, and the results are often not great.
nathan_long 8y ago
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. 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. 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. 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...
- quanticle 8y ago
  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. I agree with that approach in theory, but in practice it turns out that that it's a lot easier to estimate the costs of fixing the bug than it is to estimate the cost of having the bug. As a result, because of our biases, in any ambiguous case, our bias will be for keeping the bug, since the cost of having the bug is the impact of the bug multiplied by the probability of someone hitting it, and it's always easy to lowball those probabilities. "Oh, no one will notice that," or "Yeah, but that's a really obscure case." And then you find out that all it takes is one obscure case for your trading application to lose hundreds of millions of dollars a day. Or for hackers to breach your systems and make off with millions of credit card numbers. Or for malware to turn your IoT devices into a botnet.
debt 8y ago
Bugs shouldn't happen. Actually, in some critical systems, bugs can't happen. 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). 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. 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.
- gowld 8y ago
  What if you need features in addition to bugfixes, and you have finite resources?
- awalton 8y ago
  Maybe, but "Words with Friends" doesn't need to be written in Ada with a team of 50 engineers blowing through $20M working on proof systems for verifying the behavior of placing a tile on a board. There's maybe a tiny difference between aircraft control surface stability software and casual video games, as just one tiny example. So, obviously, as engineers we have to say that it's context dependent - bugs have priorities. And sometimes bugs exist that you can't reproduce in a lab, have only occurred once in history, and you can't even be sure it wasn't some hardware glitch (because, well, hardware is buggy too)... So, the sane and reasonable thing to do is to let those go and spend our time somewhere where we're likely to make considerable and reasonable progress.
- izzydata 8y ago
  I dare you to write 100 lines of useful code without a bug in it.
  - wilun 8y ago
    Are you even trying? A random search tells me that "The mean DD for the studied sample of projects is 7.47 post release defects per thousand lines of code (KLoC), the median is 4.3 with a standard deviation of 7.99." ( https://ieeexplore.ieee.org/document/6462687/ https://ieeexplore.ieee.org/document/6462687/ ) So clearly if you are careful and use state of the art practices, this is very doable. Not only this is doable, but various individuals and teams in history have been able to reach way lower defect densities. Hey, for all practical purposes, TeX is bug free, for example. If you are not able to write 100 lines of useful code without a bug in it (not in an infallible way, but at least sufficiently often enough), maybe you should simply study and practice to get that ability.
yurishimo 8y ago
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. 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.
mnm1 8y ago
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.
wristmittens 8y ago
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. 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.
- wristmittens 8y ago
  Not exactly the same thing but this is a similar idea of using data and algorithms to ignore the disadvantaged. https://www.nytimes.com/2018/05/04/books/review/automating-inequality-virginia-eubanks.html https://www.nytimes.com/2018/05/04/books/review/automating-i...
- twtw 8y ago
  > crucial app like Gmail ignored older browsers; Google started telling me some months ago that my browser is unsupported and random stuff has stopped working every few weeks since. I'm running circa 2015 Safari.
- trav4225 8y ago
  Something to perhaps consider: if both groups of 10 people are experiencing a bug, especially one not caused by their own doing, why is one group more "deserving" of a fix than the other?
  - taejo 8y ago
    A bad migration can be worked around by a clean install, but blindness can't, so there's one. Legal reasons are another (e.g. the Americans with Disabilities Act). OT: does anybody know of a site with similar interesting content and discussion to HN, but with a fraction of sociopaths closer to that of the general world population?
kyleperik 8y ago
> There’s no such thing as a bug free application 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. The truth is, there can be bug free applications. 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. So maybe software is like a living being in a way, that it needs to be cared for gently.
- GoToRO 8y ago
  I remember the time when people around me started using expressions like "My PC is not feeling good today." feeling It's about time, it's about having managers that were programmers and not just managers and so on. Bug free is possible for sure.
default-kramer 8y ago
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.
lurker456 8y ago
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.
phyzome 8y ago
The author of this article seems to think that occurrence frequency is the sole metric of whether a bug should be fixed. Which of these two is more important? - 0.1% of my users lose their data irrecoverably - 30% of my users get an error page and have to refresh The article never waded into this at all, which is disappointing. I don't feel like I learned anything.
ataggart 8y ago
>at a certain point, it’s too expensive to keep fixing bugs because of the high-opportunity cost of building new features. 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. 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. 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.
- wilun 8y ago
  If the only alternative is between a rewrite, and not-fixing the mess gradually, then I'll take the rewrite anytime and let the cycle continue. The problem is: is your rewrite really going to be a full-rewrite, or some kind of hybrid monster (at the architectural level, of course, there is no problem in reusing little independent pieces, if any exist)? Because you can easily fall in all the traps of both sides, if the technical side is not mastered well enough by the project management...
User23 8y ago
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.
nine_k 8y ago
Both parts of the title are correct: * Not all are worth fixing, that is, the (financial) upside of their being fixed is too low compared to the effort required. * And it's okay, that is, it's something we have to accept and live on, though it's not really nice and satisfying.
charleslmunger 8y ago
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. There are some categories of bugs that must always be fixed, regardless of how infrequently users run into them - security, privacy, accessibility, data loss. 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.
hullsean 8y ago
Thanks Kristine for the link to my article... Myth of Five Nines - why high availability is overrated https://www.iheavy.com/2012/04/01/the-myth-of-five-nines-why-high-availability-is-overrated/ https://www.iheavy.com/2012/04/01/the-myth-of-five-nines-why...

87 points by kinbiko 8y ago

"97% of respondents said they practice agile in their organization" Yeah, they all SAY they practice agile, but a lot of them practice waterfall with agile naming conventions.

scaryclam 8y ago
Or they practice not having any process and say it's agile because they constantly context switch...
betadreamer 8y ago
100%. They think they are doing agile as long as they have Sprints. Startup I'm working at right now told me "Agile" is overkill for us. But ironically it's more iterative then any company I worked before that did sprints.
- joombaga 8y ago
  > "Agile" is overkill for us. What does this mean/did they mean by this?
  - betadreamer 8y ago
    yeah being agile is good. I meant by incorporating Agile frameworks like Scrum.
- nottorp 8y ago
  Every competent programmer that I know did a form of agile (just the sane parts) long before Agile was a religion.
ken 8y ago
This number sounded suspicious to me, so I downloaded the report. What it actually says is that 97% of organizations practice some level of agile, but the percentage of teams using agile is much lower. The most common response (46%) was "Less than 1/2 of our teams are agile", for example. Saying that "97% of organizations practice agile development methods" makes it sound like it's overwhelmingly dominant, but it's not even possible to tell from these responses if a plurality of the teams who responded to a "State of Agile survey" use it, or what the most common development methodology is. This is exactly the sort of contextless figure that you'll find torn apart in "How to Lie with Statistics". > "JavaScript is more popular than ever, and over 69% of developers use JavaScript Does anyone really believe that StackOverflow surveys gather a representative sample of all developers? This same survey found that 1 in 6 developers target the Raspberry Pi (more than iOS), and 7.5% use assembly language (more than Go, Objective-C, or VB.NET). It's an interesting survey but take it with a grain of salt.

deleted 8y ago

[deleted]

nowayjose2 8y ago

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. 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.

_r_o_y_ 8y ago
It's not exactly related to your post but remember that Agile != Sprints
- qznc 8y ago
  That is like Open Source != FOSS, a lost cause.
  - matthewmacleod 8y ago
    No, it’s not. That kind of atfitude is pervasive and wrong. Loads of teams are nowhere near Scrum and work basically Kanban. That’s reasonably agile.
- nowayjose2 8y ago
  I know, but that doesn't stop managers from claiming that any process on some kind of n-week cycle is "agile". Maybe I've had bad luck, but it feels like a lot of companies pick up some agile-for-managers book and implement whichever process is there, minus the parts of the process that make them uncomfortable, and the results are often not great.

nathan_long 8y ago

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. 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. 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. 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...

quanticle 8y ago
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. I agree with that approach in theory, but in practice it turns out that that it's a lot easier to estimate the costs of fixing the bug than it is to estimate the cost of having the bug. As a result, because of our biases, in any ambiguous case, our bias will be for keeping the bug, since the cost of having the bug is the impact of the bug multiplied by the probability of someone hitting it, and it's always easy to lowball those probabilities. "Oh, no one will notice that," or "Yeah, but that's a really obscure case." And then you find out that all it takes is one obscure case for your trading application to lose hundreds of millions of dollars a day. Or for hackers to breach your systems and make off with millions of credit card numbers. Or for malware to turn your IoT devices into a botnet.

debt 8y ago

Bugs shouldn't happen. Actually, in some critical systems, bugs can't happen. 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). 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. 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.

gowld 8y ago
What if you need features in addition to bugfixes, and you have finite resources?
awalton 8y ago
Maybe, but "Words with Friends" doesn't need to be written in Ada with a team of 50 engineers blowing through $20M working on proof systems for verifying the behavior of placing a tile on a board. There's maybe a tiny difference between aircraft control surface stability software and casual video games, as just one tiny example. So, obviously, as engineers we have to say that it's context dependent - bugs have priorities. And sometimes bugs exist that you can't reproduce in a lab, have only occurred once in history, and you can't even be sure it wasn't some hardware glitch (because, well, hardware is buggy too)... So, the sane and reasonable thing to do is to let those go and spend our time somewhere where we're likely to make considerable and reasonable progress.
izzydata 8y ago
I dare you to write 100 lines of useful code without a bug in it.
- wilun 8y ago
  Are you even trying? A random search tells me that "The mean DD for the studied sample of projects is 7.47 post release defects per thousand lines of code (KLoC), the median is 4.3 with a standard deviation of 7.99." ( https://ieeexplore.ieee.org/document/6462687/ https://ieeexplore.ieee.org/document/6462687/ ) So clearly if you are careful and use state of the art practices, this is very doable. Not only this is doable, but various individuals and teams in history have been able to reach way lower defect densities. Hey, for all practical purposes, TeX is bug free, for example. If you are not able to write 100 lines of useful code without a bug in it (not in an infallible way, but at least sufficiently often enough), maybe you should simply study and practice to get that ability.

yurishimo 8y ago

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. 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.

mnm1 8y ago

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.

wristmittens 8y ago

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. 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.

wristmittens 8y ago
Not exactly the same thing but this is a similar idea of using data and algorithms to ignore the disadvantaged. https://www.nytimes.com/2018/05/04/books/review/automating-inequality-virginia-eubanks.html https://www.nytimes.com/2018/05/04/books/review/automating-i...
twtw 8y ago
> crucial app like Gmail ignored older browsers; Google started telling me some months ago that my browser is unsupported and random stuff has stopped working every few weeks since. I'm running circa 2015 Safari.
trav4225 8y ago
Something to perhaps consider: if both groups of 10 people are experiencing a bug, especially one not caused by their own doing, why is one group more "deserving" of a fix than the other?
- taejo 8y ago
  A bad migration can be worked around by a clean install, but blindness can't, so there's one. Legal reasons are another (e.g. the Americans with Disabilities Act). OT: does anybody know of a site with similar interesting content and discussion to HN, but with a fraction of sociopaths closer to that of the general world population?

kyleperik 8y ago

> There’s no such thing as a bug free application 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. The truth is, there can be bug free applications. 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. So maybe software is like a living being in a way, that it needs to be cared for gently.

GoToRO 8y ago
I remember the time when people around me started using expressions like "My PC is not feeling good today." feeling It's about time, it's about having managers that were programmers and not just managers and so on. Bug free is possible for sure.

default-kramer 8y ago

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.

lurker456 8y ago

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.

phyzome 8y ago

The author of this article seems to think that occurrence frequency is the sole metric of whether a bug should be fixed. Which of these two is more important? - 0.1% of my users lose their data irrecoverably - 30% of my users get an error page and have to refresh The article never waded into this at all, which is disappointing. I don't feel like I learned anything.

ataggart 8y ago

>at a certain point, it’s too expensive to keep fixing bugs because of the high-opportunity cost of building new features. 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. 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. 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.

wilun 8y ago
If the only alternative is between a rewrite, and not-fixing the mess gradually, then I'll take the rewrite anytime and let the cycle continue. The problem is: is your rewrite really going to be a full-rewrite, or some kind of hybrid monster (at the architectural level, of course, there is no problem in reusing little independent pieces, if any exist)? Because you can easily fall in all the traps of both sides, if the technical side is not mastered well enough by the project management...

User23 8y ago

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.

nine_k 8y ago

Both parts of the title are correct: * Not all are worth fixing, that is, the (financial) upside of their being fixed is too low compared to the effort required. * And it's okay, that is, it's something we have to accept and live on, though it's not really nice and satisfying.

charleslmunger 8y ago

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. There are some categories of bugs that must always be fixed, regardless of how infrequently users run into them - security, privacy, accessibility, data loss. 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.

hullsean 8y ago

Thanks Kristine for the link to my article... Myth of Five Nines - why high availability is overrated https://www.iheavy.com/2012/04/01/the-myth-of-five-nines-why-high-availability-is-overrated/ https://www.iheavy.com/2012/04/01/the-myth-of-five-nines-why...