If behavior is strange, you want to know if it was expected to be that way, and why. You can use the developer's line of reasoning to prioritize. If you understand the conditions that brought the hack, you are better prepared to maintain the code.
The article suggests that most problems should just be fixed right away, instead of leaving "someday" comments. But, a few weeks of maintaining a large code base will cure anyone of this belief. Not everything can be fixed right away, for many reasons:
- Maybe there isn't time, due to pressure to complete X or Y.
- Maybe it's risky to just hack in the first solution that pops into your head, and you need time to come up with the right fix.
- Code bases can be very complicated. You're not usually working on your own brilliant creations, you're working on things that many other people did, and some of them had no clue. You are tinkering with an engine you didn't design, and you have to be careful.
- The bug might actually be important in the short-term. One of the evil realities of large code bases is that "bugward-compatibility" can matter, and "fixing" something may cause more immediate problems than it solves.