Find a compromise between predicting too much of the future and just managing a project by the seat of your pants; get into a rhythm where you check how good your estimations and learn to get better at them.
Of course you can't develop every project this way; I've used Agile and it's worked for me. I've used waterfall and it's worked for me too. You have to try to be sensible; you can't completely wall of other people's need to know when you'll accomplish certain things, nor can you build a solid plan based on pure speculation. You have to have an intelligent responsible way of dealing with future uncertainty, a plan to cut it down to size.
I've even had the good fortune at one point of winning a $750,000 grant to build a system for which no firm requirements had been established. It was kind of an uphill-flowing waterfall: we knew how long it would take us and how much it would cost but we had no firm idea of what we were supposed to build. If that sounds like a recipe for disaster, it was; but my team was *successful* and built a product which was still be used and supported over a decade after the grant finished.
What's missing from many programming estimates is honesty. It's a matter of ethics; you can't take people's money and say maybe someday you'll deliver something useful to them. People don't have unlimited time and money to accomplish all the things that need to be done in the world. It's an honor being entrusted with people's aspirations, and a serious responsibility. It's hard, even nerve-wracking, but you've got to care enough about the impact of your planning on other people to make the effort to do the very best job you can.
And what I've found is that if you do make the effort you can do a surprisingly good job of estimating a project if it's in an area and with technologies you're reasonably familiar with. If you look closely your specific predictions will often be way off, but if you care enough to be brutally honest the pleasant surprises tend to balance out the unpleasant ones.