We also break rules. Frequently. I have a habit (a rule) of going to the gym every morning before work. This morning, I slept in and broke my habit. No gym for me this morning! Now, this was just a habit, so breaking it wasn't a huge deal. There aren't a lot of consequences for that breakage.
In 1995, Montana got rid of numeric speed limits. Going 100 mph wasn't necessarily speeding, as long as it was "reasonable and proper." And people hated it. They made statements like, "two years on the road with the crazies out there" made them afraid they would be "going along at 80 and someone from out of state, who doesn't understand the road conditions, passes you at 100." (source). Eventually, Montana imposed numeric speed limits again. They had their rules back. The only flaw in Montana's reasoning is that with no speed limits, there were actually fewer fatalities. Having no speed limits was safer, but having the rules made people feel better in the abstract. Oh, and people still speed; they just like to have speed limits around.
So how does this apply to software?
Well, instead of "speed limit", let's say "rules to release software". This gets pretty interesting. Many (most?) companies have rules about when to release software. These rules (or guidelines, or best practices, or targets) tend to take the following form:
Any software we release can have 0 P1 defects, and no more than X P2 defects. Further, the software must have successfully passed Y tests for 1 week prior to release.
There are of course variations on this theme. One commonality, though, is that the rules are bent or outright broken as the release date approaches. That defect that was a P1 last month but still hasn't been fixed.... well, that really should be a P2. The tests for a week prior to release..... well, maybe 3 days is fine.
We make the rules. Then we break them. But we still have the rules we make.
Why? Because it makes us comfortable.
With a rule for releasing software, or a known end point, we know we have to consider the release criteria: the number and priority of open defects, the state and stability of testing, etc. We may choose to change our criteria at the last minute, but at least we know those criteria are there and therefore we keep an eye on them. Rules for releasing software are guidelines to where we look and to things we consider. In the end, a release decision is always a gut decision. Someone holds her breath and says, "yes, let's release." Having rules and criteria helps guide that gut decision.
So don't throw away your rules. And don't expect to stop bending or breaking them. Just understand what the rules are giving you: comfort and a framework for making decisions. No more, no less.