Mmmm. Old code. You're a very lucky man. It's easy to be a good programmer when all you have is good code (or no code, which is the same thing) to work with. It's very difficult to be a good programmer when presented with bad code. However, it is only through adverse conditions that one learns about oneself, and it's only through success in obviously adverse conditions that one can impress one's superiors.

At a previous contract, I was working in a team of, roughly, 5-8 programmers on an application that was pretty important to the business. This app was a replacement of a previous app written on Windows (but was still maintained) and whose replacement already existed (but was still in v0.64beta status). It was also horrendous. I mean, it worked (which is priority 1) and made the business lots of money (which is priority 2), but the code was very hard to maintain.

I saw an opportunity. There were some 80 reports that had to be outputable in HTML and PDF. We used HTML::Template, but rolled the PDF by hand using PDFLib. There was a PDF::Template out there, but it was very poor. After proving I could support the current PDF wrapper around PDFLib, I went to my group leader and suggested extending PDF::Template to meet our needs. He said that the risk was too great. Ok. I went back to my drawing board and came up with a development cost and a rollout plan. Then, I waited.

About a month later, a major bug was discovered in the PDF wrapper. I tracked it down and saw my chance. I very slightly overestimated the cost of fixing the bug to where it came close to PDF::Template's cost, then presented my case, suggesting only to convert those reports impacted by the bug. I stressed the benefits of the conversion, including the fact that the 20 new reports coming down the pike would have their development costs cut in half with a greater assurance of no bugs in the PDF section. I stressed the reduced maintenance costs (which were considerable in the PDF area). I got the go-ahead to spend 4 weeks on PDF::Template. (I estimated a 100 hour bug to be 130 hours ... close to 160, neh?)

Remember - very few bosses want higher development and maintenance costs. What they do want is reduced risk. However, reducing risk next month at the cost of increasing risk this month is unacceptable. You have to demonstrate how you're reducing risk later without increasing risk now. Usually, this means phasing in any improvements over 2-4 releases. And, that's ok.

Also - you have to prove yourself first. Yeah, they hired you, but that just means you can do the job. In the first 3-6 months is when you prove that you will do the job. After you have some minor successes, go after a medium job. Then, a major job. After I implemented PDF::Template, I was given free rein to do whatever I wanted. So, I put into place a completely new reporting system. However, I only converted those reports that were being touched anyways. That was (and is) the plan until about 60-80% of the reports are in the new system. Then, it makes sense to convert the rest, because it becomes obvious that it is a greater risk to leave them as is than it is to convert them.

And, follow all the advice above. Tests are your friend.

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.