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).