I did this so often, it became known as "Gathman's Law" at our office. "Software problems are best fixed by identifying and deleting the offending code."
In contrast, we sometimes had to deal with code from a large company (that shall remain unnamed) where problems were apparently fixed by adding code to test for the failure condition, and force the correct result in that case. The resulting bloated code left us wondering how much was logically reachable.
I would always just comment out code, rather than delete it, because quite frequently the specs would change anew and 'undo' the original change. I saved myself much extra effort that way. In fact, we would get so many 'final versions' of the specs that they were referred to as 'the latest final version'.
From one of our development team meetings:
PHB: "Ted, what did you accomplish this week?"
Ted: "I solved a major performance problem in one of our programs".
Dilbert: "Who originally wrote the program that had this major performance problem?"
The accomplishment was not deleting the two lines.
The accomplishment was to identify the problem, tracking up the source and come up with the solution to delete the two lines of code. Without needing to re-write a lot of the system. Of course you do not know how long it will take until you go to the process.
Identifying the problem, tracking the source and come up with a solution takes a lot longer than actually implementing the change. As a programmer, Dilbert is supposed to know that.
Glad to see that, for the first time, Ted is appreciated.