There is obfuscation---a feeble palimpsest---and then there is inherited production code.

When there is revision control on the software, employers get upset if you change too much at any one time. You make a change to handle bug 237 or change request 1743, a problem is found during testing, and diff shows 3700 changed lines. ( of course, if there isn't even revision control, you should run, not walk, for the nearest exit.

One strategy I've used is to take some idle moments and go over the code, thinking what changes I would introduce. Then re-read M-J Dominus's Red Flags articles, or some of merlyn's articles, where long, badly-written programs collapse into short, efficient scripts.

Once you have a strategy, you can introduce your changes. As far as I'm concerned, for each line of code that I need to modify in the line of duty, it's fair play to modify a line of code because it improves the program.

If you need to modify a couple of print statements, simplify a loop at the same time. If you need to implement some new capability in the counter which audits and reports what happens to each line of input, replace the existing counter with an object ... duplicated lines are refactored into methods, comprehensability is improved since the intent is clearer, the code runs faster, and fewer lines are changed than if you added the new code in a dozen places throughout the program.

Then, next month, you can look at the DB handling .....

--
TTTATCGGTCGTTATATAGATGTTTGCA