Breaking The Rules

[Limbic~Region]

All,
There is an unwritten creed amongst us hackers with regards to the rules of programming. When it is doled out, it is usually in the form of admonishment. This tradition often leads to the uninitiated chanting cargo-culted mantras. There are of course published style guides and books devoted to best practices. It seems that everyone has an opinion on the matter. If we were each to publish a manifesto on the rules of programming, I seriously doubt any single item would be universally accepted.

It is not uncommon to hear arguments such as:

Sam:  I am writing a widget to do X and am stuck with foo.
Bob:  Don't reinvent the wheel, use Y
Sam:  I know about Y, but I want to learn it for myself
Sue:  So why not learn how the author of Y did it
Bob:  Fine, but keep it in your sandbox (no CPAN or production)
Sam:  I want to share it because Y doesn't do Z
Sue:  Why not subclass or provide a patch for Y
Tom:  If you publish, pick a good name and explain when to use your wi
+dget over Y

Sam didn't recieve the help he desired with foo because everyone felt Sam was breaking one of the rules. They had different opinions on the matter, but the outcome was the same. The great advice provided by Bob, Sue, and Tom may not have even registered with Sam. It was likely assumed that Sam possessed the knowledge and experience to understand why the counter-arguments were valid reasons for caution. Unfortunately, it is seldom the case that the uninitiated fit that assumption.

There is seemingly no end to the things we are or are not supposed to do:

• Don't parse (HT|X)ML with regular expressions
• Don't reinvent the wheel
• Don't prematurely optimize
• Always use strictures
• Always use warnings
• Always use revision control

For every single rule, there are exceptions. Wars are started over which exceptions are valid or not. So how is the uninitiated supposed to decide for themself? Here are my rules for breaking the rules:

• Use extreme prudence
• Experiment to gain personal experience

Prudence amounts to thinking through what might go wrong and taking necessary precautions. You don't have to rely on your just your own knowledge. You can search the web, read the manuals, ask around. You will have to utilize your situation specific context to know how, if at all, to apply this information.

It has been said that there is no substitute for personal experience. I encourage experimentation but warn that, without common sense and prudence, dragons lie ahead. You may still get burned or eaten alive, but if you live to battle another day - apply the knowledge you have gained. That's why they call it experience.

In summary, don't blindly follow the rules or be afraid to break them. Think for yourself and make sound judgements.

Update: It is ultimately your responsibility to understand why the rules, exceptions, and advice exists. Ignoring advice from others is not in the spirit of this meditation and you must realize the ramifications of your experimentation on others. If you decide to reinvent a wheel and use it in production without bothering to learn from the existing wheel or ensure your code passes the applicable tests from that test suite you are not using common sense, prudence, or sound judgement.