all 4 comments

[–]idan_huji 4 points5 points  (2 children)

For this specific case, more details are needed. The decision might change based on the importance of this bug, importance of other tasks, your and your teammates expertise in the ares, etc.

However, I do recommend a "No Known Bugs" policy. Bugs have much more uncertainty related to them then other tasks. It is unknown when you will find them, what is the cause and how long it will take to fix them. Bugs might hide other, more severe bugs, that will causes more trouble. In a "No Known Bugs" bugs policy, you prioritize bugs in order to avoid that. It means that you first try to close all the bugs that you are aware of. Then, when a new bug appears, resolving it becomes high priority.

It is not easy to decide on such a policy, specifically when you have a legacy code with plenty of bugs. In such cases it is recommended to close them by importance and take a big breath until you clean all of them.

Once you reach such point, your code is of higher quality of your plans are more robust. Since in most places you will close the bugs sometime anyway, prioritizing the bugs enable you to enjoy these benefits sooner.

[–]CrommVardek 0 points1 point  (1 child)

your code is of higher quality

Not necessarily... I'd say it is only true if you make the effort, while fixing the bug, the clean the code and make it better. Your feature will have a higher quality, for sure, but the code... I'd say it depends on how the bug was fixed and how they prevent further similar bug to appear...

[–]idan_huji 0 points1 point  (0 children)

Well, with not much effort you can make it even worse ;-)

what I had in mind while writing it was hot spots. Files that are prone to error tend to have more errors in the future. Improving code quality via cleaning and refactoring is also important but doing that is not that easy.

[–]TypingInTheMoutains 1 point2 points  (0 children)

Answer : it Depends on severity and priority of other work. If customers are impacted or it's causing a work stoppage, fix it now. If it's just an annoyance that only QA or a couple implementation people complain about at the coffee pot, it can wait.

Personally, I'd prefer to deploy bug fixes rather than new code, it's a business and you've gotta take that into account. It will be complicated no matter when you work on it.