5 ms·

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

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.

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.