In truth tooling fixes a lot of his issues with OOP. E.g. "you will have to check the entire code base for any methods which called the setter." Sounds diffic

In truth tooling fixes a lot of his issues with OOP. E.g. "you will have to check the entire code base for any methods which called the setter." Sounds difficult... But it's really less than a second away as OOP IDEs have a "find references" functionality. Likewise if you want to know who is setting a bad value you just set a data breakpoint and the debugger will break when the bad value is set. More fundamentally I don't agree with his assertion that figuring out where the bug is is the most time consuming part of debugging. The most time consuming part by a very large margin is setting up the environment to properly replicate the defect, followed by retesting all surrounding code/features that could be impacted by the fix, followed by determining a fix, followed by documenting/management overhead. The average time for me to find the location of a bug in our codebase is around an hour. Yet I only fix on average a bug a day and it's not because I head to the pub after finding it :p.