Reminds me of Knuth's paper 'The errors of TeX'. He had logged all bugs he made while programming TeX and classified them. Paper is online here:<p><a href="https://yurichev.com/mirrors/knuth1989.pdf" rel="nofollow">https://yurichev.com/mirrors/knuth1989.pdf</a>
I do think among the most common bugs is the <i>increased understanding of the problem domain</i>.<p>Code often does what it is intended to do, but the result is wrong because the problem wasn't actually sufficiently understood when the solution was formulated.<p>If you have a function that for a given integer N returns a value m=f(N) so that m²=N, and you run the function and get positive m:s on weekdays and negative m:s on weekends (on x86, the happens opposite on ARM), we're quick to say that's a bug.<p>No, it's just a surprise.<p>The function works as advertised, that f(N) would be identical to sqrt(N) is just an assumption you made that isn't found in the specs. The requirements never said anything about the sign of m, that's a requirement you added retroactively when it wasn't behaving as you expected.<p>I think this is very often the case with the experience of those "how can this have ever worked"-bugs. You were never surprised by the behavior because you never examined it particularly closely before.
The Heisenbug: a software bug that seems to disappear or alter its behavior when one attempts to study it.[0] They're rare, but they do happen.<p>[0] <a href="https://en.wikipedia.org/wiki/Heisenbug" rel="nofollow">https://en.wikipedia.org/wiki/Heisenbug</a>