Not all bugs are worth fixing and that's okay • Hacker News Board

Re: Not all bugs are worth fixing and that's okay

#41

Post by dgreensp » Wed, Jul 25, 2018, 10:36 PM UTC

wilun wrote: post #33

ryandrake wrote: post #23

Earlier quoted context omitted.

One of the toughest things I struggled with while transitioning from a larval junior developer to a senior tech lead to a project manager was the fact that (at least in the context of a for-profit business) not all bugs need to be fixed, even the ones you personally think are really really bad. The goal is to make money, not necessarily by producing the most perfect software. The quality bar needs to be high, but the…

That's fair, but one has to remember that some of the key points are to be balanced, and that, like you said, "the quality bar needs to be high". And I'm more for prioritizing trying to not introduce bugs than to fix all the old ones. Which is challenging on, how could we call that?, "legacy" software. So that priority can and must be reversed temporarily when that "legacy" is too much. So it's all very context depen…

This is my experience as well. Product progress is prioritized over code quality, and the ultimate cost to velocity is real but often unacknowledged. Bugs go unfixed because they are very hard to fix, and this high cost is taken for granted.

It’s definitely on the technical leadership to stand up for code cleanliness and push back against product, and on the higher-ups to recognize the importance of this dynamic.

Re: Not all bugs are worth fixing and that's okay

#42

Post by rajangdavis » Wed, Jul 25, 2018, 11:09 PM UTC

ryandrake wrote: post #23

nowayjose2 wrote: post #6

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 blata…

One of the toughest things I struggled with while transitioning from a larval junior developer to a senior tech lead to a project manager was the fact that (at least in the context of a for-profit business) not all bugs need to be fixed, even the ones you personally think are really really bad. The goal is to make money, not necessarily by producing the most perfect software. The quality bar needs to be high, but the…

Totally understand that a project can't be perfect, and I could be wrong, but I feel that if there are a lot of bugs, the project scope is too big and/or the requirements are not well understood.

There is also the matter of really picky customers; however, if a customer can articulate what you are doing wrong, I don't think that it's a bad thing if they are picky.

Quality should be in step with expectations; selling services that can't be achieved with in a specific time slot is worse than trying to fix all of the bugs.

Re: Not all bugs are worth fixing and that's okay

#43

Post by nine_k » Wed, Jul 25, 2018, 11:17 PM UTC

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.

Re: Not all bugs are worth fixing and that's okay

#44

Post by nowayjose2 » Thu, Jul 26, 2018, 12:04 AM UTC

loopj wrote: post #36

nowayjose2 wrote: post #6

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 blata…

Heads up - I co-wrote this article with Kristine and this is based around the whole thesis of our company existing - I'm a software developer by trade with 15 years of experience. Having said that, dismissing the content based on the author I think comes across as an ad-hominem attack - after working with her for 4 years I count Kristine as an expert on this matter. The overall point here isn't to use this as an excu…

I just want to note -- I didn't dismiss the article based on the author's background; I was baffled after reading the article because it made no sense to me when I was reading it from the perspective of someone I initially assumed was a developer. I'm not really sure how someone can develop expertise in software development without having participated in the process, but if you cowrote the article maybe you can explain? Do you agree 97% of developers are following agile principles and that this stability formula is a good way to measure the overall bugginess of an application?

Re: Not all bugs are worth fixing and that's okay

#45

Post by nowayjose2 » Thu, Jul 26, 2018, 12:11 AM UTC

coldtea wrote: post #35

nowayjose2 wrote: post #6

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 blata…

> 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. If they're not noticeable, and the customers keep buying, despite 100% of them having them, how are…

The bugs will be very noticeable to stakeholders who are not end users, if they decide to look. The users don't buy the software because they want to; they buy it because they are required to. If groups we're supposed to be accountable to see the shenanigans we're up to and say, sorry no dice, you have to try again with some other company that made their software properly, _then_ the users will be upset because they'll be out mucho dinero for nothing. The end users don't know what rules we're supposed to be following on our end, nor should they have to.

Where I come from, if software doesn't meet requirements and instead produces incorrect results, it's considered a bug. To use another example from a different company I've worked for, I once found out that the financial reports generated by a particular piece of software were all completely wrong due to errors in the way calculations were done. I pointed this out to the higher-ups and they agreed that there was a bug and that all the existing financial reports were in significant error. They refused to let me fix it, not because we didn't have time (there was plenty, and I was otherwise free to work on pretty much whatever was in the backlog), but because fixing the bug would let the customers know that there was a bug in the first place. Some of this data would end up getting passed on to shareholders and the government. Is this not a bug? In the current case, the reason we're not complying with the rules was because of a bad architectural decision that wasn't properly cleared with anyone before it was implemented.

I guess I'm just not on board with the "just following orders" school of software development when the negligence involved rises to the level of illegality and scams. I'm happy to write a lot of software that I personally think is wonky or strange, but for me it stops when we start ripping people off and breaking the law.

Re: Not all bugs are worth fixing and that's okay

#46

Post by User23 » Thu, Jul 26, 2018, 12:12 AM UTC

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.

Re: Not all bugs are worth fixing and that's okay

#47

Post by User23 » Thu, Jul 26, 2018, 12:15 AM UTC

loopj wrote: post #36

nowayjose2 wrote: post #6

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 blata…

Heads up - I co-wrote this article with Kristine and this is based around the whole thesis of our company existing - I'm a software developer by trade with 15 years of experience. Having said that, dismissing the content based on the author I think comes across as an ad-hominem attack - after working with her for 4 years I count Kristine as an expert on this matter. The overall point here isn't to use this as an excu…

The opening Dijkstra quote is out of context and deeply misleading. See https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD303... for his views on the subject.

Re: Not all bugs are worth fixing and that's okay

#48

Post by nowayjose2 » Thu, Jul 26, 2018, 12:26 AM UTC

_r_o_y_ wrote: post #7

nowayjose2 wrote: post #6

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 blata…

It's not exactly related to your post but remember that Agile != Sprints

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.

Re: Not all bugs are worth fixing and that's okay

#49

Post by nowayjose2 » Thu, Jul 26, 2018, 12:30 AM UTC

Retric wrote: post #8

nowayjose2 wrote: post #6

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 blata…

Agile is not about the details. If you are producing shippable versions of your product every 2 months or less then your probably Agile relative to what existed when the term was invented.

Maybe if you mean little-a agile, as in the dictionary definition "moving quickly". Big-A Agile, as in the set of software development principles, has a bit more to it than that.

http://agilemanifesto.org/principles.html

Re: Not all bugs are worth fixing and that's okay

#50

Post by natalyarostova » Thu, Jul 26, 2018, 1:59 AM UTC

loopj wrote: post #36

nowayjose2 wrote: post #6

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 blata…

Heads up - I co-wrote this article with Kristine and this is based around the whole thesis of our company existing - I'm a software developer by trade with 15 years of experience. Having said that, dismissing the content based on the author I think comes across as an ad-hominem attack - after working with her for 4 years I count Kristine as an expert on this matter. The overall point here isn't to use this as an excu…

It's not an ad-hominem. It's an inference on the predictive power of the article as a function of the commenters prior belief on the expertise of non-developers.

They may or may not be right, but you can't just dismiss things you don't like by classifying them as a "fallacy."