Agile process smell: Hardening sprint

Many people have discussed a hardening sprint in the past, some for and some against. I'm definitely in the latter category.

I've been in teams that have haven't had them and ones that have introduced them.

Hardening sprints tend to get introduced for the best of intentions. The team has spotted that they are having problems with quality and want to do something about it. Great, but the first thing that generally comes to mind is to do lots of testing before every release. This fixes the symptoms but not the underlying issues. Also what happens if you have to release unexpectedly? These underlying issues really need to be uncovered and dealt with, but that isn't the focus for this post.

Hardening sprints point to a process smell. The team should be dealing with their quality issue as the code is being written, not well after. There should be a whole team and company commitment to quality. Having these sprints can cause us to defer quality until just before release. It also breaks the completed stories should be potentially releasable rule.

There are numerous things a team can try without resorting to a hardening sprint.  I've listed a few below:

Take a look at implementing TDD.
Have testers and developers collaborate more as the code is being written.
Pair test.
Have acceptance criteria before planning which form the basis of acceptance tests.
... and more.

Do you have a hardening sprint before release? What are the benefits from having one? Alternatively what are your reasons no to have one?
Shared publicly