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