>The rules do not exist in a vacuum, they exist for a reason. The reason is that many before us have been down the road and found out how they messed up later.

Fits with what I said. You break the rules when you know what and why, and know how much it's gonna cost you. So your filosophy of breaking rules is practically equivalent to mine... just that I don't make rules on breaking rules, I play by the ear. I either hear myself think "no, I don't want to run into _that_ trouble, better go safe", or, rarely, "the regular way would take too long, and, besides, I won't replicate this elsewhere".

>The problem with this is that all too often rules are broken, not because that was the best way to do something, but because someone did not know any better.

I forgot that. I meant only deliberately breaking, not ignorantly.

>Breaking a rule should never be an easy decision. I tell my students that if they feel that they want to break a rule they should;
>
>1. Fly to the desert
>2. Drive into the desert
>3. Walk farther into the desert
>4. Find a place with no shade and sit there of 30 days
>
>If at any time they decide not to break the rule, come home. If after the 30 days they still want to break the rule, then come home and break the rule.

That's OK for students. Once they get into the real world... see what Marc wrote.

Another matter: most of the quick'n'dirty solutions are against the rules, or may not be supported in future, or a simply written for one-time use. They are OK as such, they solve an immediate problem. I'm just not sure what percentage of programmers revisits those bits of code after a while. They are tomorrow's stumbling stones, and apps containing them deserve a periodical clean up. That's what makes version numbers get their decimals. I know I rehash my apps at least once a year (well, the more popular ones, at least).