Deadlines are bad, goals are good
Deadlines are a fact of life. If someone throws a football at your face, you have a certain amount of time to block it before the ball smashes into your face. Does software planning work the same way? That depends on the type of software you're writing.
If someone else is assigning your deadline, you don't really have a choice. The IRS might need that new tax software in time for the tax season, or the whole government will come crumbling down. In that case, you pretty much have to get it done no matter what. To miss the date would mean catastrophe. Features will need to be trimmed as necessary to complete the job. This type of planning is known as deadline driven scheduling.
Boy that sure sounds great! Pick a due date, and it's done! Why wouldn't everyone do that? Well, for one, it only ensures that your software goes out on time, not that it's good, or that it does what you want. Most people choose this method under the incorrect assumption that they're helping the project, when they're severely hurting quality.
The alternative method of planning a software release, is to pick your features, and calculate a release date. If you have actually made a conscious decision to make sure that your features get completed, and get completed well, the due date is actually a goal. By making it a goal, you can relax a little bit. If you're implementing a new feature and you estimate it will take 2 days, you might realize that to do it right will take an extra day. Hopefully you'll have a good project lead that can make prioritization decisions, make sure everyone stays on task, and can accurately plan in some padding for things that were not in the original design. In the end, you'll end up with a good product.
I think this page makes a good point:
"Creating software is both an art and science. It is an art because there is quite a bit of creativity involved. It is a science because it ultimately involves engineering a logical set of instructions."
It should be very obvious that creativity is impossible to schedule, and even with a good plan, good ideas are missed.
Can you have your cake an eat it too? Of course. The theme is speed, quality, and price. You can pick two. This post assumes that it's a compromise between speed and quality, on whatever fixed budget you have. If you have a virtually unlimited budget, then there would obviously be more choices available to you.
Of course, as with anything, these are simply guidelines. People haven't been writing software and perfecting software engineering for hundreds of years. We're using an evolving process, that is undoubtedly in its infancy. If you're using something that works, good for you! If you care to take the time, leave a comment and let me know what you've learned while writing software.