What's Wrong with Exceptions?

I think the 1999 NEC has an Achilles’ Heel, and it has to do with the conversion of exceptions “into positive text” as a step towards supposed clarity and usability. The Usability Task Group raised this possibility early in the cycle, and properly so, based on some very successful history. The classic example was the 1993 work in Sec. 240-21, with its 11 tap rules, before then as exceptions, and subsequently recast as positive text.

Somehow that kind of example became, for some panels, like the magic broom in the hands of the Sorcerer’s Apprentice. Entire articles now stand denuded of all exceptions, too often through mindless conversion of italicized exception text to stranded, uncitable conflicting paragraphs. Now, in fairness to the Task Group, those panels wildly overreacted to what the group recommended, but nevertheless, overreact they did, and neither the Task Group nor the Correlating Committee adequately contained the result.

It isn’t easy to do it right. Making these changes in a user-friendly way isn’t straightforward. For example, suppose you have a rule that says do “x”, and an exception that says if “z” is true, then you can do “y”. When you convert that exception to normal text, you now have two stand-alone requirements of equal rank. The first says always do “x” and the second says sometimes you can do “y” — a direct conflict.

The only way to properly eliminate an exception like that is to go back and rewrite the parent rule to say you must comply with one of the following two options, as applicable. Then, rewrite first “x” and then “y” as subparagraphs to the parent rule. This is extremely difficult and time-consuming work to get exactly right without introducing unsubstantiated technical changes. Let’s face it, it just didn’t happen in far too many cases.

Actually, a carefully crafted exception, written in the form of a complete sentence, is a very user friendly device. It should apply to a limited set of circumstances and it should never be an editorial contrivance to break up a long sentence that incorporates a single rule that applies generally. Properly focused, however, it grabs the reader’s attention because it appears in a contrasting typeface. It’s easily and specifically capable of citation. Ironically, the last major editorial revision of the Code under the direction of Walter Stone in the early 1970s converted a lot of positive text to exceptions exactly because they enhanced clarity.

We need editorial continuity. There is a larger issue, however. The most user-unfriendly part of this exercise actually isn’t that some panels messed up perfectly good exceptions. In a way, it’s that only some of the panels messed up. The result is extremely discordant text as you move from one panel to the next in the book. Art. 230 has almost 40 exceptions; Art. 240 now will have none.

One of the best NFPA staff liaisons in the electrical group makes the point that the NEC isn’t written in English; it’s written in Code. He has a point. One of the reasons that fog analysis doesn’t realistically measure the accessibility of the NEC to people starting out is that as you stay with it, you learn the language. We lose that editorial continuity at our peril.

The test of usability is readability. We can dramatically improve the syntax and usability of the Code, while retaining essential editorial continuity, but only through an attention to editorial quality that approaches our attention to technical detail. The Correlating Committee has to address this through a consensus process that will ultimately lead to clear, comprehensive, and enforceable editorial guidance to the Code Making Panels. The present NEC Style Manual needs massive revisions to do the job. One panel just cited the Style Manual in refusing to correct a blatant violation of established rules of English grammar.

The Correlating Committee reconstituted the Usability Task Group. This time, I hope we get focus on the editorial problems that make User A and User B read the same passage and draw opposite conclusions. That’s where the rubber meets the road—not in elaborate reorganizations that only disrupt the established user knowledge base. We at EC&M stand ready to play a constructive role in such an effort.