5 ms·

It would be a good software development practice if they fixed it in a couple days top. It is not really acceptible if such a bug survived so long.

adreamingsoul 7y ago
I disagree. Placing a time cap on finding , fixing, and documenting the root issue of a bug incentivies beating the clock over working the actual issue. However, this all depends on the buisness goals for a software development team. If long term stability is not that important, then I can understand why a time cap for fixing a bug is encouraged. Ideally though I would encourage developers to find organisations that allow developers to understand the root of an issue before fixing it.
- shultays 7y ago
  You can always do the both. If there was an "easy" fix that can be applied in a day or two, it should have been done. Take all the time you think you can afford if yyou software is not released. But it is being used by customers and such a large bug is in it and if you are not reacting to it then imo it is a problem. I think people disagreeing with me is unable to see from the perspective of customers. In this case a player that loses hours of progress because of a bug deserves some atention
  - cvs268 7y ago
    > You can always do the both. > If there was an "easy" fix that can be applied in a day or two, > it should have been done. Agreed. However, when someone asks for this, the implicit assumptions are that the "easy fix" - actually fixes the symptoms (even though ignoring the root-cause), - and does NOT introduce additional unexpected behaviour. Ensuring this may sometimes make the easy fix just as time-consuming as a proper fix, thus favouring doing it once properly.
  - marcinzm 7y ago
    Unless you understand the root cause of a bug there is no guarantee that an easy fix won't cause it's own problems. And if a system us so complicated that you cannot understand the root cause of a bug before doing a fix then it's very likely that the fix will have unexpected side effects. The end result is more rather than fewer bugs.
deleted 7y ago
[deleted]
CydeWeys 7y ago
You are underestimating how seriously difficult some bugs can be to diagnose. I've seen super difficult bugs in large complex systems take over a month of dedicated effort to solve, despite the eventual fix being only a few lines long. That's the kind of bug where you take dozens of pages of notes as you puzzle through figuring it out. And this is at Google, with smart engineers. As the old saying goes, it's knowing where the problem is that's hard.

adreamingsoul 7y ago

I disagree. Placing a time cap on finding , fixing, and documenting the root issue of a bug incentivies beating the clock over working the actual issue. However, this all depends on the buisness goals for a software development team. If long term stability is not that important, then I can understand why a time cap for fixing a bug is encouraged. Ideally though I would encourage developers to find organisations that allow developers to understand the root of an issue before fixing it.

shultays 7y ago
You can always do the both. If there was an "easy" fix that can be applied in a day or two, it should have been done. Take all the time you think you can afford if yyou software is not released. But it is being used by customers and such a large bug is in it and if you are not reacting to it then imo it is a problem. I think people disagreeing with me is unable to see from the perspective of customers. In this case a player that loses hours of progress because of a bug deserves some atention
- cvs268 7y ago
  > You can always do the both. > If there was an "easy" fix that can be applied in a day or two, > it should have been done. Agreed. However, when someone asks for this, the implicit assumptions are that the "easy fix" - actually fixes the symptoms (even though ignoring the root-cause), - and does NOT introduce additional unexpected behaviour. Ensuring this may sometimes make the easy fix just as time-consuming as a proper fix, thus favouring doing it once properly.
- marcinzm 7y ago
  Unless you understand the root cause of a bug there is no guarantee that an easy fix won't cause it's own problems. And if a system us so complicated that you cannot understand the root cause of a bug before doing a fix then it's very likely that the fix will have unexpected side effects. The end result is more rather than fewer bugs.

deleted 7y ago

[deleted]

CydeWeys 7y ago

You are underestimating how seriously difficult some bugs can be to diagnose. I've seen super difficult bugs in large complex systems take over a month of dedicated effort to solve, despite the eventual fix being only a few lines long. That's the kind of bug where you take dozens of pages of notes as you puzzle through figuring it out. And this is at Google, with smart engineers. As the old saying goes, it's knowing where the problem is that's hard.