As others said...
1) approach boss / PM proactively & be honest
But, I would also add...
2) be honest that
a) you're forging new territory with the tools / code you're using (ie: you're not an expert, so they can't make project assumptions based on you being an expert in it)
b) it's a big hairball mess you're trying to untangle.. which increases
i. ) the time it takes to learn the code
ii. ) the time it takes to make changes
What this will tell your project manager is that when it comes to time estimates (which PM's love, and which they try to hold everyone to) your estimates are just a shot in the dark and are wildly inaccurate. Not out of malice or stupidity.. just because this is new territory for you to cover, and the territory is very hostile (crap code).
So, instead of asking you for exact time cut offs (eg: "10 days to do this, 5 days to do that"... Critical Path Method / CPM time estimation) .. they should instead expect estimated ranges of time... more of a "I think it'll be 10 to 20 days before I can get this done."
And if they ask why the wild time range estimates.. you'll need to speak Project Management lingo and say you're switching to more of a PERT (Program Evaluation & Review Technique) Time Estimation method.
What PERT does is require people working on milestones to provide 3 time estimates...
optimistic (when it can get done in the 1% situaition when god is smiling on you and everything goes right)
pessimistic (the 1% time when satan is just pooping all over your project and nothing goes right)
most likely (a time you feel comfortable in hitting 50% of the time)
It's important to underline the fact that "most likely" is not "I'm 90% sure I can get the thing done in this time". No.. it's "50% of the time I can hit this estimate".
Because the opt, pes & most likely estimates map out to a bell curve in PERT...
opt = +3 std dev to right
pes = -3 std dev to left
ml = -2 to +2 std dev's inner bell curve
avg time to finish milestone = ( opt + ml x 4 + pes ) / 6
std deviation estimate = ( pes - opt ) / 6
(a PERT bell curve assumes 6 std deviations, because a +/- 4th std deviation level is going way out into "astronomically unlikely outliers" territory.)
PM's would take the time estimates and can do z-scores to get probability curves on when things will be done.
But, bottomline is that PERT is used to figure out which milestones are hazy.. something new and different enough that makes folks give shakey estimates will have a wider range then a milestone that someone has done before and is very confident about.
Your boss (if they're a PM or versed in Project Management) should hear the word "PERT" and start to understand that maybe they need to rethink how they view you working on the task.
Because while PM's often dig into the PMBOK and learn a lot of math and six sigma stuff.. eventually in the real world they get lazy and just switch to CPM methods or what-not and simply ask people to give them a SINGLE NUMBER time estimate for a milestone.
That's great for them.. b/c they don't have to calculate stuff to fit it into their network diagram and project tracker.
But, it sucks for the worker bee like you.. b/c then they hold you to an exact number / date... and in a project where you're doing something wildly different then what you've done before.. you don't need that kind of pressure.
It's also just good to let a boss know that, while you are a programmer, that doesn't mean you're an instant expert on everything programming.
I was employed as a an analyst / report runner at one place attached to a project management department, and I knew some coding so I automated a few things. Since I did that, they thought of me as "coder guy". So, one day director approached me to build out an interactive web site.. like ASP, HTML, the whole nine yards.. was going to be a company-wide project tracking web-site.
I'm looking at him dumbfounded, because he didn't seem to understand that a) that was WAY out of my wheelhouse, b) even though it was, I knew that what they were asking was something you would usually hire a team of prorammers to do.
I had to have an uncomfortable chat with the guy.. and I had to put it into language he could understand.
"Imagine you, the director of project managemet got transferred to be the director of billing"
"Ok.. that would be a change of pace, but I don't see what the big deal would be..."
"... in china."
"But, I don't speak chinese."
"Oh." (suddenly he realizes what he was asking of me)