It seems odd that, in order for a rule to be valid, there has to be an exception. According to the well-known phrase “the exception that proves the rule”, this must be the case. Yet watching a TV quiz show the other week, I was amazed to discover that one of the rules I’ve applied most days of my working life as a writer is actually completely wrong.
If you went to school more than a few years ago, you’ll no doubt be familiar with the spelling rule “i” before “e” except after “c”. For all my working life this rule has allowed me to correctly spell words such as “receipt” and “ceiling”. Yet, for some unaccountable reason, I never thought of applying it to words such as “leisure” or “being”. They just naturally have “ei” in them.
And I assume that’s why I always wonder about writing “friend” instead of “freind.” I suppose we’re back to the “ghoti” (fish) conundrum here. Though now I use Word all the time, I end up spelling words like this (friend, not fish) accurately just because Word automatically corrects them. Try typing “freind” with Word’s AutoCorrect feature turned on (the default setting) to see what I mean…
Anyway, the point about this quiz show and the “i” before “e” rule is that it is actually a non-rule. Whereas there usually needs to be at least one variation that proves a rule, it seems there are twenty one times as many words that break this rule as there are words that comply with it. At the last count, there were 489 words in the Oxford English Dictionary that contain “ei” without a preceding “c”. In fact they say the rule is so useless that they no longer teach it to kids in school. Perhaps we can look forward to recieveing emails from our grown-up kids telling us how much our new grandson Kieth now wieghs, how the christening party went, and how at the hieght of the celebrations somebody managed to put their foot through the bedroom cieling.
But I guess our own industry is just as vague about defining general rules for the design and implementation of software. As I’ve discovered (and ranted about in the past), almost any question you ask a software expert about almost any topic of architecture or code results in an answer that starts with “Well, it all depends on … [insert a complex mix of conflicting circumstances here].” Try it yourself. Next time you are at a cocktail party and find yourself standing next to a software designer, ask them if Command Query Responsibility Segregation will make your semi-normalized Domain Driven Design model easier to implement in a multi-node, clustered, cloud-hosted solution.
Or how many developers are required to change a light bulb (from a search of the web, it seems the answer is “none” because it’s actually a hardware problem).