When children learn to read and write, they are often taught to memorize spelling rules. In English, you are probably familiar with “I before E except after C.” (I would list more, but I never actually memorized any of them. :) For every rule, there are of course exceptions: eight, height, caffeine… The exceptions may not always make sense, but fluent readers and writers internalize them and understand that the simplified rules that we are taught as children are not sufficient to describe the complexity of a living language.

Visual artists are taught rules of design, the sort of thing that the rest of us find in books like The Non-Designers Design Book. Once they have achieved a level of mastery over these rules, they know when to break them. They understand that the rules are conventions.

Then there are programmers.

I don’t want you to think that I believe this of all programmers — it may even be a minority — but I regularly encounter developers who are made deeply uncomfortable by deviation from rules that they have understood to be set in stone but that in practice can be adapted fluidly. Or those who are just unwilling to accept that there are classes of problems that don’t have a single, clean solution.

I have an unsubstantiated, wild-ass hunch that they’re the same people who work on formal, mathematical proof of the “correctness” of programs. I say this not to impugn their character or ideas, simply to try to understand. I have a liberal arts background, so this is still a foreign way of thinking for me.

(By the way. It may happen that one or two people I’ve talked to recently about these topics will think I’m talking about them. I’m not. Get over yourselves.)

Let’s take web standards as an example. It should be no surprise to long-time readers that I am a web standards advocate. The three-legged stool and all that. I believe that unobtrusive JavaScript is an important and useful way to use standards to best advantage. But I am not a zealot. Sometimes it’s just not practical to take extreme measures to avoid behavioral attributes like “onclick” in your HTML. Maybe you’re using a framework that generates that code, and you can’t get away from it. It’s okay. Take a deep breath. You’ll live. I’ll live.

And then you’ll create something like the UJS Rails plugin to address a shortcoming in your framework of choice. Bravo! I knew you could do it.

Even the standards leave room for plenty of controversy, or at least wiggle-room. Is the kerfuffle over serving XHTML as text/html still going on? I really don’t know. I stopped paying attention years ago but still feel twinges of guilt about recommending XHTML Strict as a standard at work.

Security is an example of a problem that is likely to have less-than-ideal solutions. Consider threat modeling, an important part of a secure software development life cycle. In the threat modeling process, you identify and assess threats and vulnerabilities to your system, identifying those that pose the greatest risk. Security is risk management. It’s a balancing act: if there’s a low likelihood that a vulnerability will be exploited or that it will cause much damage if it is exploited, then you may choose not to devote development resources to creating countermeasures. Sometimes one security solution causes another to pop up elsewhere, and you have to decide which poses the greater risk. It’s ugly. I know.

Accessibility is another of those murky areas. In almost every conversation I have about accessibility, questions arise without satisfactory answers. Are PDFs accessible? They can be. It depends. Is this JavaScript technique accessible? For some people, yes. For others, no.

In all these situations, it comes down to making an informed, professional judgment. Novices do not have the knowledge necessary to make these judgments. That’s what makes them novices. That’s why children learn simplified spelling rules, why budding designers are taught the rules and conventions of their field, why beginning web developers should learn to use web standards and accessible development techniques. Adopting these rules and putting them into practice, over time we bump up against when they fail us. In time we develop a sense for how we can best respond to these failures, to this discord. We learn how best to move past the rules because we understand why they are there in the first place.