DEV Community

Cover image for Code Smell 179 - Known Bugs
Maxi Contieri
Maxi Contieri

Posted on • Originally published at

Code Smell 179 - Known Bugs

Every software has a list of known bugs. Why?

TL;DR: Don't track bugs. Fix them.


  • Hard to-track lists

  • Technical Debt

  • Functional Debt


  1. Stop calling it a Bug

  2. Reproduce the Defect.

  3. Cover the scenario with automation

  4. Make the most straightforward fix (even hardcoding solutions)

  5. Refactor

Welcome to TDD!


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



function divide($numerator, $denominator) {
  return $numerator / $denominator;  
  // FIXME denominator value might be 0
  // TODO Rename function
Enter fullscreen mode Exit fullscreen mode



function integerDivide($numerator, $denominator) {
  if (denominator == 0) {
    throw new DivideByZero();
  return $numerator / $denominator;  

// we pay our debts
Enter fullscreen mode Exit fullscreen mode


[X] Automatic

We need to avoid creating bugs and issues.


  • Technical Debt


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.


More Info

Famous Bugs


Code Smells are just my opinion.


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)

cloutierjo profile image

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.