Schrodinbug...

Schrodinbug...  That's a new word for me, learned when I read this article.  I've run across a few schrodinbugs myself over the years, far too often for their existence to be merely chance or coincidence.  In at least a couple of cases, I was able to track down the authors (there always seem to be two :) – and I discovered that one bug predated the other, and the later bug was deliberately created to compensate for the first bug.  There are lots of scenarios where the foibles of the ordinary humans who write software would cause this.  For instance, suppose a very senior, well-respected engineer accidentally created a bug like the one described in the article.  Then one could imagine a very junior, timid engineer trying to use that code, running into the bug, and then either assuming that the first guy must be right, or simply being afraid to approach that first engineer.  The natural result of that would be to write the compensating “counter-bug” to get the correct result despite having two bugs.  In one of the cases where I talked with the authors, I'm pretty sure that's exactly what happened.

Something I've seen much more often than straightforward, provable code schrodinbugs are what I'll call “architecture schrodinbugs”.  For example, suppose an engineer implements a working, but poorly designed API (this is so common one could consider it to be the norm!).  After that, there may be many programmers who write contorted code that uses that API – in effect, every one of them is a counter-bug, and the pair of the crappy API and the resulting twisted client is an architectural schrodinbug.  They're also how most software is built :)