Re: So I'm in a bit of a quandary

[hacker]

3. My boss was the original author. I'll obviously have to tread lightly so as to not offend.

A few things come to mind:

1. Were you hired to be a perl programmer?
2. Is your skill level with perl expected to exceed that of your boss?
3. Does your boss still actively contribute/write/maintain any company perl code?
4. Is your boss going to be paying for your time to update/fix this code?

If your boss is still actively writing production perl code under these conditions, he puts the company at risk, depending on the nature of the code. If he does not write or maintain any company perl code, he could have written this at a time when -w -T and strict were not stressed as much as they are now.

Good programming practices are important, but spaghetti code is never excusable.

One approach you may want to try, which will allow you to do the rewrite, and at the same time not offend your boss, is to try to convert the code into a module/package-based piece of code, using proper OO concepts (this assumes of course, that the existing code is monolithic, and not modular). This will allow you to do the rewrite, and hide the inadequacies of your boss' code in more maintainable code.

Another approach is to go through it and "update" the code to work better with "current" perl and industry standards around usability and security. A rudimentary 'audit' of the code could be performed, to show where it would fail under certain conditions. Put it under load, fire different variables/inputs at it, etc. and see where it breaks down.

One thing I've always learned.. I improve my code and myself when people are critical of me. If everyone were to compliment my code, I'd never have the incentive to improve it. If everyone were to pick my code to death and find problems with it, I know exactly where I need to improve.

Perhaps the direct approach with your boss might also prove fruitful. He may respect your forwardness and experience, and allow you to fix it. Maybe you can teach him why those "missing" items are important to use, and how each piece of "broken" code could be improved to be faster/more-secure and so on.

[oakbox]

Another approach is to go through it and "update" the code to work better with "current" perl and industry standards around usability and security.

If your boss is still programming, even he probably looks at his 'old' code and cringes a little bit. I had a very similar experience recently. While the company couldn't afford a complete re-write of that piece of code (not mission critical) he DID see the value in going through and making it run under strict and -w.

If the code IS mission critical, selling a re-write of the code to OO shouldn't be a problem. If there is any chance that this code will be used going forward, or if it has functions that might be used by other callers, this would be a good time to make those functions cleanly available to other callers.

oakbox