http://www.perlmonks.org?node_id=180140


in reply to So I'm in a bit of a quandary

Ah, code maintenance diplomacy when the author is a superior. Tricky. Saying the code sucks and you want to essentially do a code base rewrite to implement a new feature obviously isn't likely to be a good strategy --- unless your boss is uncommonly ego-less and honest about his own code. How forthright you are in expressing your opinion of his code is something you'd best judge for yourself, but it isn't necessary to bash older code in order to argue for significant changes. What do you want? What does your boss want? How does what you want apply to what your boss wants?

On impulse and from a future maintenance perspective I would like to re-write it .

Impulse and the future aren't likely to cut it. The most important factor to focus on is the here and now --- the new feature. Arguments about future maintenance and growth may not seem immediate enough to justify large rewrites of working code at the present time. Even if *you* know that hacking the new feature onto the current system will take a significant portion of the time a major rewrite would take, it won't necessarily *sound* that way to your boss. Arguments about present speed or reliability will fail to be convincing if everything has been working fine for two years of production use.

Trying to find a nice way to explain the re-write is proving harder than I imagined.

You need to make the case that the heavy rewriting, refactoring, and modularization you are proposing will help you reliably implement the new feature in a timely manner. That's what your boss wants after all, right? Criticizing the lack of -w and strict, global variables, or poor style or structure, aren't likely to win your case. The thing works after all. One non-criticizing angle you can try is to argue that the present requirements exceed the original design and that a certain amount of refactoring is a necessary and good thing for the task at hand. Review the code base from this perspective and see what kind of case you can come up with. Speed, maintenance, and future growth arguments can be layered over this, but these may well be secondary issues in terms of what your boss wants now. If you really want to improve the code base you may have to settle for a more modest refactoring strategy rather than a complete re-write.