There have been a few occasions where something is totally, unexplainably broken. I usually spend a few hours working on it, stepping through the entire execution of what is invariably multithreaded code, and just cannot find what’s wrong.
A few days ago, my job queue just wasn’t working nicely with collision callbacks. You can attach “collision listeners” to rigid bodies in Havok, so when they collide, your implementation of the collision listener gets called. The problem I was seeing was that one callback in the listener seemed to cause one or two other callbacks to get fired when it was processed. So every time a worker thread processed a job, the queue would stay the same size.
After a while, I just decided I’d comment it out, ignore it, and hope that it would get fixed automatigically at some stage later. After doing some work on areas of code related to the listener today, I uncommented the buggy code and it worked! The job queue never gets more than one entry in it now!
This has happened a few times, and I’m a big supporter of ignoring buggy code after a certain amount of effort doesn’t fix it. I’ll just write a note about it somewhere, leave it alone, and when I check in on the broken code a few days later something else has fixed it.
I believe this is thanks to all the refactoring I do. Cleaning up how objects interact with each other usually ends up working wonders for fixing “weird” behaviour.
When I read this, I thought ‘hmmm, sounds like Microsoft’s development ethos’, except the problems get fixed.
I see Systems Analysis and Design has taught you a few things, NOT