Enjoyed this. Safe multithreading requires knowing everything that can have its state changed and managing it. That's all but impossible unless we encapsulate and strictly limit what state can be changed.
My last big bug was along the same lines. I was working in an oddly-designed class with lots of inheritance. It's hard to describe, but it was written so that changing its internal state was necessary even when it shouldn't be. The developer didn't understand how to make a class testable, so every method that should have been private was public and changed the state so that a unit test could verify it.
That developer was also the architect. After I refactored to fix all of that, he didn't like it and insisted that I roll back every line of it. That included putting back unused variables and restoring method names that had nothing to do with the methods. (Did I mention that the entire class was copied and pasted from other classes, and that the copying and pasting was mandatory? I am not kidding, he made a video explaining how to copy and paste his code so he wouldn't have to waste his precious time explaining it over and over.)
Having put all of that back, I failed to account for one of the state changes, and it severely impacted performance.
It's the most frustrating type of issue. It was my bug. I introduced it. At the same time, I avoid bugs by making code testable and eliminating the types of side effects that make bugs easier to make. In other words, the strategy isn't to make everything incredibly complicated and then try to mentally keep track of it, but rather to make it simpler so that in any given context there's less to keep track of and it's easier to test.
Enjoyed this. Safe multithreading requires knowing everything that can have its state changed and managing it. That's all but impossible unless we encapsulate and strictly limit what state can be changed.
My last big bug was along the same lines. I was working in an oddly-designed class with lots of inheritance. It's hard to describe, but it was written so that changing its internal state was necessary even when it shouldn't be. The developer didn't understand how to make a class testable, so every method that should have been private was public and changed the state so that a unit test could verify it.
That developer was also the architect. After I refactored to fix all of that, he didn't like it and insisted that I roll back every line of it. That included putting back unused variables and restoring method names that had nothing to do with the methods. (Did I mention that the entire class was copied and pasted from other classes, and that the copying and pasting was mandatory? I am not kidding, he made a video explaining how to copy and paste his code so he wouldn't have to waste his precious time explaining it over and over.)
Having put all of that back, I failed to account for one of the state changes, and it severely impacted performance.
It's the most frustrating type of issue. It was my bug. I introduced it. At the same time, I avoid bugs by making code testable and eliminating the types of side effects that make bugs easier to make. In other words, the strategy isn't to make everything incredibly complicated and then try to mentally keep track of it, but rather to make it simpler so that in any given context there's less to keep track of and it's easier to test.
Ouch. I'm sorry. Everyone needs the best chance at success possible. Loved your comment.