Code Smell 179 - Known Bugs

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

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!

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

Code Smell 148 - ToDos

Maxi Contieri ・ Jul 13 '22

#javascript #webdev #beginners #programming

More Info

Famous Bugs

Stop Calling them ‘Bugs’

Maxi Contieri ・ Mar 22 '21

#codenewbie #tutorial #oop #testing

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

Software Engineering Great Quotes

Maxi Contieri ・ Dec 28 '20

#codenewbie #programming #quotes #software

---

This article is part of the CodeSmell Series.

How to Find the Stinky parts of your Code

Maxi Contieri ・ May 21 '21

#codenewbie #tutorial #codequality #beginners

Comments

[cloutierjo]

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.