The best way to do hardening sprints

What's the problem with hardening sprints?

Hardening sprints are often considered a sign of mis-interpreted Agile and a process smell. But then I read in answer to Ron Jeffries, who pointed out that hardening sprints simply mean that you where not "Done" the first time around.
In that answer I read that should be almost always due to overcommitment.
Really? Well - I've never seen this.
If I see hardening sprints at all I usually see teams putting the hard part last and then ending up with a huge number of 98% done stories that will be "fixed right before the release" - of course this accumulates and the transaction cost of the release become higher and higher until you end up with a whole Sprint to fix the small things that now form a huge, interconnected blob.

The solution

Get to "DONE" early. Not as in "code complete" or "checked into source control" or "automated tests did run" or even "accepted by client" but as in "There is nothing left that has to be done for this story" Just don't do hardening sprints!

Additional comment: When the requirements conform to INVEST so should the implementation

The (well know?) INVEST formula for story-design put independet as the top property of a good user-story.
But what good is an independent requirement if the implementation is strongly coupled with other stories? Of course there is a limit to the independence, especially if you have a newer story relying of an already "done" story. But an older story should never be dependent on a later story (Really bad: "it will work once we've got the implemented, so let's just consider it 'done' for now") and the stories of one iteration should be as independent as possible.