Fetishes -vs- Patterns

I was going to write a rant on what I’ve come to call “Software Fetishes,” or the use of valueless patterns by organizations, but honestly I’m too headachy to take it to any satisfying conclusion.

Suffice to say that a fetish:

Is largely unimportant to the general health of the system;

Is easy to defend in the right meetings (“How hard can that be? Sounds like a good idea. Let’s enforce it across the board.”)

Is very nearly (but not quite) automatable with your favorite Emacs clone, if you had the time to figure out a decent macro.

Approaches the quality of “cargo cult” programming after a while (e.g., holy formatting wars — “Why do we do we format function declarations this one exact way?” turns out to be because of someone’s decade-old crappy parser requiring it, not anything rooted in articulatable engineering principles, but really the opposite).

Fetishes are hard to bust up because code that doesn’t follow them looks different, and is easy to spot. The org can’t say why a practice is important, but it will enforce meaningless conformity anyway.

There, I’ve stated the problem. I’ll try to come up with some examples and solutions later (as soon as the walls stop pulsing, ow ow ow).