Trigger happy programming

You come across an issue like say, the code is dog slow. What is the course of action? For the stuff I do for fun, I rewrite the whole thing. But being a responsible citizen, I don't do such things at work. Here is what I do; (for a more philosophical discussion of problem solving refer to 'zen and the art of motorcycle maintenance')

I have been programming for a while, I am entitled to have a hunch. So I do a bit of 'shotgun debugging' which consists of randomly fixing pieces of code which look like probable causes, hoping that the problem goes away. Sometimes it does go away, we go to the pub.

There should be a limit tho where you start to experiment in a more controlled way. Measure, change one bit, measure again. Change only one bit at a time. The transition between two modes of action determines a programmer's 'trigger happiness factor'.

There are two considerations, usually highly correlated, to make the call for the mode switch; the amount of programming time required and the depth of code that will be replaced.

I have seen people replace whole sub systems on a hunch, spending months. Some are good programmers and can get away with it, I am usually cautious.

Anyway, there is no conclusion here, all you have to do is to keep it real.