Re: Program size and effeciency.

[qq]

They have given me a older project to take care of and to clear bugs in them.

Start from the bugs. Clean up as you go, and only so much as you need to.

Resist the temptation to start from scratch, because you'll get blamed for whatever new bugs you introduce. Remember that you'll find a lot of seemingly non-sensical lines of code - but each was put in for a reason, and some may be crucial. Until you are very familiar with the problem at hand don't assume you know all the wrinkles.

qq

[zakzebrowski]

I agree with this node. What I would additionally recommend you do is to start writing tests. That way, if you change one thing in the old code and it causes a bunch of stuff to fail, you can then consider inserting your favourite perl module as a "quick test", and if the perl code passes the test, (or if you can tinker with the orignal code to make it work, without causing other things to fail), you could be golden. Good luck!

[exussum0]

Or you'll get blamed for having to take a long time to perform the smallest change. I remember once dealing with such a system.. took me a week to change the price of something. People got all excited when I finally got it. Scary stuff.

One time, I did get permission to rewrite a piece of that system... you were right, people did get annoyed when new bugs came up. BUT, after the bugs settled, it was the fastest and easier piece of the puzzle to modify. Some time passed, and they were doing efficiency analysis on the system to see where they could improve on it. Turns out the part that got rewritten was skipped since it was the fastest part of the entire thing. :)

Yes, tooting my own horn, but thought I'd share the positive experience of rewriting, and the negative of not rewriting. There /are/ times when you shouldn't. Just not never.

[demerphq]

I've has an similar experience to the one you describe here. I need to make a simple change to a critical piece of code in the system I am responsible for after the coworker who wrote it had left the company. He had given me a walk through indicating what needed to be done, and essentially suggested it was a trivial change. Unfortunately time didnt permit me to do the change with him, and once he had gone it turned out that what he had explained was wrong. I spent a week debugging the code, tracing through the code, etc. And got nowhere. Changes I made seemingly did nothing. As I knew there were changes coming along that would be much more drammatic I decided that given a trivial change was turning it a huge effort the future changes would be signifigantly more difficult, and frankly not worth the time. End result I wrote a total replacment, in only a little more time than it had taken to decide the old code was unmaintainable.

That replacment provided a strong foundation for the much more drammatic enhancements that came down the pike. The time invested in rewriting and restructuring the code paid off big time as the new code base is much easier to extend, and has been pushed far beyond any of the changes I had thought were coming. Had I persevered with the original code base and taken another week to get that trivial change in place the stuff that came after would be impossible.

I think what the OP needs to do is present a structural argument as to whether the code base should be refactored. If the argument is convincing his boss will give him permission.