>I'll be working on a project for a system that I've just started learning. I will be making significant changes and also creating some things I'm not familiar with (creating services, working with ports, etc.). I need to give an estimate on the time I think it's going to take to do all this, but I'm having a hard time coming up with a way to do that. I normally find estimates hard, pretty much take an educated guess, add on 30%, and hope I'm close. Anyone have a better way? Thanks!

You can't estimate what you don't know.

Obvious, huh?

If you don't know the technology or if you don't know the "real" specs, there is no basis to estimate.

One way to get closer to having a better estimate is to do it in phases.

Phase 1:
Play with the new technology.
Services and Ports take some time to learn.

Phase 2:
Make a "Paper System" with screen shots, notes on how it will work, lists of processes that have no screens etc.

Phase 3:
Get real feedback from real users.
It should take at least 3 intense meetings to hammer out the real specs.
If they say "Looks ok to me" without needing changes, then run away real fast.

Phase 4:
Have yourself and another developer look over the list for omissions.
Do this separately and then together.
If you don't find any omissions, repeat until you find some.

Phase 5:
Have yourself and another developer create estimates for each piece.
If any pieces are over 2 days, break into smaller pieces.
If you can't pass the gut-clench test about a piece, then go investigate until you really know what you have to do.

Phase 6:
Meditate for 2 days

Phase 7:
Arbitrarily inflate the estimate by some magic number.

Good Luck!