Paper: How Do Fixes Become Bugs?

I found this page that has the Best Paper Awards in Computer Science (since 1996) so I thought I’d read some papers, starting with this one, How Do Fixes Become Bugs?, Zuoning Yin, University of Illinois at Urbana-Champaign; et al.

It’s well written but mostly tells you what you already know.  However it does provide some quantifiable results to prove what seems obvious.  Some of the results include:

  • A lot of bug fixes either don’t fix or cause new bugs (14.8%∼24.4% among the four OSes the evaluated).
  • Concurrency bugs (race/deadlock) are the hardest types of bugs to fix, 39% were )not fixed correctly.
  • Memory bugs (unitialized read, memory leak, null pointer reference) were next with 14% not fixed correctly.
  • It is best to have the person who wrote the code, fix the bug, or at least review the fix.  Of course they are probably busy developing new code.

The one I didn’t expect, but does make sense is that developers are more likely to make incorrect changes on Friday, When do changes induce fixes? (J. Åšliwerski, T. Zimmermann, and A. Zeller).