It's an unfortunate fact of life that some of the subsystems we depend on (function libraries, operating systems, etc.) contain bugs. These bugs are harder to deal with, of course, because we can't always fix them ourselves; we may not even have the sources, let alone the time and wherewithal to debug and recompile them.
When you find it necessary to work around a bug in such a subsystem (or any kind of bug, for that matter), make sure your code will keep working (without change) on the day the bug does get fixed. Otherwise, your code may be enlisted as an excuse not to fix the bug, unless you can be convinced to "fix" your code at exactly the same time. Soon enough, if too many pieces of code work around the same bug in inflexible ways, the bug becomes cemented in place, and can't be fixed no matter what, because it becomes effectively impossible to "fix" all those pieces (especially if the installation of all the fixes has to be synchronized).
If a buggy system becomes popular, it often proves impossible to improve or replace it -- all of its new versions, and even its from-the-ground-up, reincarnated replacements, must be "bug-for-bug compatible" with the original, so that all the workarounds and kludges that surround it (in all the pieces of code that depend on it) will continue to work. But "bug-for-bug compatibility" is the death of progress: when bug-for-bug compatibility becomes a requirement, systems stagnate instead of growing, since progress becomes impossible.
This page by Steve Summit // about these challenges / previous next