Every software has a list of known bugs. Why?
TL;DR: Don't track bugs. Fix them.
Problems
Hard to-track lists
Technical Debt
Functional Debt
Solutions
Stop calling it a Bug
Reproduce the Defect.
Cover the scenario with automation
Make the most straightforward fix (even hardcoding solutions)
Refactor
Welcome to TDD!
Context
We don't like to be interrupted.
Then, we create lists and delay fixes and solutions.
We should be able to change software easily.
We need to improve our software if we can't do quick fixes and corrections.
Not by creating To-Fix lists.
Sample Code
Wrong
<?
function divide($numerator, $denominator) {
return $numerator / $denominator;
// FIXME denominator value might be 0
// TODO Rename function
}
Right
<?
function integerDivide($numerator, $denominator) {
if (denominator == 0) {
throw new DivideByZero();
}
return $numerator / $denominator;
}
// we pay our debts
Detection
[X] Automatic
We need to avoid creating bugs and issues.
Tags
- Technical Debt
Conclusion
We need to discourage bugs and issue trackers on the engineering side.
Of course, customers need to track their findings and we need to address them ASAP.
Relations
More Info
Disclaimer
Code Smells are just my opinion.
Credits
Photo by Justin Lauria on Unsplash
In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.
Joel Spolsky
This article is part of the CodeSmell Series.
Top comments (1)
We have a rules in our team, if you find an issue, tech debt or any code improvement and it take less time to "fix"it than start a discussion, open a ticket, manage that ticket and then get back to understand the issue in a few weeks/months, just fix it now. Rules of thumb less than 30 minute, just do it.
But if it's a very larger issue then we need to plan the fix. Last year we had a few issues related to the same code (since issues like to group together) and the root source of the issue was a bad architecture of that part of the code (namely a poc that was put in production!). We did as much work around and quick patch as possible but the real solution was to fully rewrite that part which took roughly 6 months. There is no way a dev could have done that without planning that time and the new architecture properly.
And still those original issue were very small, a date badly computed, a value that took way too long to retrieve.
So in the end, i stand with our rules of, fix it now if quick otherwise officially track it so it can be planned.
And finally, i do agree with your closing statement, fix issues and debt quickly as their cost compound over time. Even if issues are tracked, we need to plan them and not just pile them in a known issue list.