A Taxonomy of Bugs
ourmachinery.com
ourmachinery.com
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.
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.
No, it's just a surprise.
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.
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.
This isn't waterproof though. I think TDD-code prima facie upholds its promise to keeping down the code complexity per module, this is often at the expense of the bigger picture architecture. You go from spaghetti code to ravioli code; hardly an improvement.
(Yes, we’re still supporting it for some reason)
Appropriately enough, this line contains a bug.