One of the less fun things about working as a software engineer is estimates. They're very difficult to get right, often pushed early by the client who naturally wants to know how much a project is going to cost them, and you'll sometimes get held to early wild guess estimates when they turn out to be terribly wrong. I enjoyed this Slashdot discussion on the topic, and there's some truth to this facetious comment:
I just ask my manager how long he's already told the client it's going to take.
At the moment, most estimates I do are done within a Scrum context, using Planning Poker or similar estimation methods. Planning poker is very simply trying to take all the pressure out of the estimation work; forget about what the client is expecting, forget what your project manager is expecting and never mind the experience of your colleagues. The estimates are not hours but relative complexity: start with a simple task and give it 2 points. Everything else is just relative from that. All developers on the team lay down their estimate card on the table at the same time, removing the bias of less experienced developers emulating the more senior developers. I know I sound like a geek when I say: it has put the fun back into estimation for me, and resulted in more accurate estimates.
I'm looking forward to the day though, when we as a business move away from expecting that we know the exact shipping feature set or cost at the start of a project. If you read any account of software projects throughout the few decades that such expectations will turn out to be wrong almost invariably. At the same time, I have respect for the client who wants to know what they're getting and at what price.
It's a difficult problem to solve.