Touching it when it ain't broke

[Marza]

During the discusion of So you know Perl; but do you know programming?, Abigail-II remarked the old saying "Don't touch it if it ain't broke"

After pondering this statement. I tend to think that there is a good time to "fix" something.

Usually, it can be argued that it is a waste of time since we are always doing something on the job. However, my question is now this:

Why not fix things if you are going to have to make major mods on the script anyway? The perfect time would be before the new feature is added. You already know what the script is doing so if you do something wrong, you can respond quickly. A "cleaner" script might make the additions/mods faster

Then, there is the fact you also add time to the job.

All in all, I would think changing it when you are making mods are justified.

Hmmmm can I be a perfectionist?

:-o

Just some ale induced wonderings on a late Thursday night

[oakbox]

So I'm in a bit of a quandary has a discussion about updating old scripts in a production environment and how to deal with some of the social issues around it. One thing that I got out of the conversation is that there are three basic criteria to look at when contemplating a rewrite:
1. Do you need to rewrite the script to add functionality now or in the future? A rewrite to make it easier to update will save you time in the future.
2. Is the script a security hazard? Is it broken in some fundamental way that compromises your security?
3. Do you require a boost in efficiency to handle higher traffic loads?
It looks like you are in situation 1. You need to look at your current update and how likely is it that future updates will be needed?

oakbox

[Marza]

Thanks! Well after hunting and killing a small keg of ale, the super search function gets really hard to use! ;P

You are correct in that my situation is number 1. The script in question has many future "updates" planned by my boss. So a re-write does make the planned changes easier. Especially now that I am smarter then when I first saw this script. ;)

Thanks for the link! ++

[Ovid]

If it works, but you have nothing else to do, what I would recommend is starting a comprehensive test suite. Then you can refactor at will and have instant knowledge of whether or not your changes broke things. For any system of significant size, trying to make sweeping changes without a test suite is a recipe for disaster. You wind up testing everything by hand and you will miss something. Of course, you'll miss things with a test suite, too, but then you write a new test for what you missed and continue on your way :)

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[pdcawley]

Hear hear! I've worked on site where the existing code is sufficiently complex, and the existing test suite so non existent, that we've ended up applying the 'Extract Algorithm' refactoring to give ourselves a restricted set of well tested functionality, and then added tests and refactored towards the same functionality as the old code.

It seems scary at first, but old code with no tests is scarier still. Especially when that code is a tightly coupled mess of objects with no consistent naming style, let alone a consistent code layout style. Our new code doesn't do everything the old code does. Yet. But it's reasonably clear, naming is consistent and IT HAS TESTS! Tests are great. I really cannot recommend them highly enough.

[Zaxo]

There is an extended discussion of maintainance and refactoring code at So I'm in a bit of a quandary.

After Compline,
Zaxo

[hsmyers]

While I tend to avoid fixing that which isn't broken, I always consider if the code in question can be made better. I've tried to do my best with the folksong maxim:

"...make it better and pass it on..."

--hsm

"Never try to teach a pig to sing...it wastes your time and it annoys the pig."