Working in the Technological Stone Age: Databases and software help and hinder NFPA’s code developments

Shutterstock / ModVector / NotionPic
Shutterstock / ModVector / NotionPic
Published On
Nov 15, 2021

I became the secretary of the National Electrical Code in the summer of 1989. Work on the 1990 Code had just been completed, and the closing date for the 1993 Code cycle would not be until Nov. 9, 1990. I had a great mentor, Peter Schram, who had taught me a lot over the previous three years. I also had a very solid technical staff behind me. What could go wrong?

The day-to-day activity was mostly technical. However, there was the other stuff that the military likes to call logistics—all that behind-the-scenes stuff that makes things appear to happen seamlessly. Although 1990 doesn’t seem like that long ago, from a technology standpoint, it was practically the Stone Age. Proposals and comments were submitted on paper well in advance of the closing date, because no one wanted to be shut out of the process due to postal delays. Many did send their submissions through FedEx, UPS or DHL, and it was another cycle or two before a fax machine was installed. On the last day to submit proposals or comments, we had to check all the fax machines at 5 p.m.

Data entry was another issue. Some proposals and comments were typed; others were handwritten. All of them had to be entered into NFPA’s word-processing system, which consisted of a Wang word processor and language. They also had to be proofread against the original.

We would mail copies of original proposals or comments to the panel members. Once all of the material was entered into the word-processing system, we would mail typed material to the panel members. Sorting the entered material took about two weeks. Individual agendas were developed for each of the 20 Code -Making Panels.

For the 1990 cycle, the agendas generated by the system were unusable because the section numbering in the NEC resulted in an agenda that could not be sorted into Code order. Computers recognized 240.1, 240.10 and 240.100 as the same number, and sections 240.11 and 240.12 would sort before 240.2. I had a couple of long discussions with a member of NFPA’s information services staff about the mess this created. His recommendation was that we needed to abandon the word processing system and go to a database. A database would allow us to break down the section numbers into elements so they would sort.

FileMaker Pro

Selling the idea wasn’t easy, because NFPA had invested a lot in its word processing system. Ultimately, it was decided we should try it. A database was created using FileMaker Pro, an off-the-shelf program. It also provided a solution to a long-standing problem of ballot errata, because the section numbers did not need to be rekeyed. Agendas and ballots could easily be generated.

The database templates were designed for the NEC and were later adapted for the rest of NFPA’s codes and standards. It worked extremely well for 20 years. One of its best features was the ability to search in fields. For example, I could look for a keyword or phrase in just the substantiation field. I could also find all of the proposals from a given submitter, state, etc. The entire file could be sorted in less than one minute.

The FileMaker database worked primarily as an internal tool to log proposals and comments and record actions. It lacked an important functionality: a public interface to submit proposals or public comments directly into the system. This was important, because some changes being proposed were based on prior editions of the Code . In addition, every time material gets rekeyed, errors can be introduced. Submissions in the new system are a markup of the existing Code text. This ensures that there is an accurate record of additions and deletions. Another feature that the FileMaker database lacked was secure online electronic balloting, which was added to the new system.

TerraView

TerraView (or just Terra), the new software tool, provides online access to allow proposed changes to be made directly to the document text. The changes are shown legislatively, and each proposal (now called a public input) would be a separate record. The actual document would not be changed. Starting with the current Code ensured that the changes were being made to the current edition. It also ensured that the text reflected the changes and no words were lost. Words to be deleted are struck through, those being added are underlined and words that weren’t changed appear normally. Public comments follow a similar process, but comments are developed based on the first draft report.

Most NFPA documents are developed in accordance with the NFPA Manual of Style. The NEC operates under the NEC Style Manual, which means that Terra had to be modified for the NEC .

Terra hasn’t worked flawlessly. Submitters are often frustrated with what happens to their public input or public comment. Although the tool is supposed to show changes in legislative format, it turns out this is not easy to do. In Terra, it is only successful if the text is simple.

The NEC has many places where requirements are expressed in list format, and this is where Terra is at its worst. It has become a bigger problem because many NEC requirements have been reformatted into lists to make them easier to understand. Terra makes a mess out of lists, and, in some cases, it inserts extra returns. In many cases, it displays text as changed, even though that part of the text wasn’t. It also messes up list numbering, and there are limited editing tools for the Code text field, which is the only field that has editing tools.

I may be more familiar with the tools than most other users, so I could fix some problems because I know how to override the list formatting. However, Terra identified some things as changes that were not.

One major advantage of FileMaker was the ability to sort proposals and comments and to generate lists in order. TerraView can generate an agenda, but it doesn’t necessarily sort the material in the right order. Some material may be several pages away in a printed order or PDF document.

Terra doesn’t work well in meetings, such as the NEC, where there are multiple, simultaneous meetings. It is cumbersome and slow. Often, the staff work in Word and enter the information in the software later. Terra also requires more staff than its predecessor. How is that progress?

The substantiation field that is displayed during entry of public input or public comments is very small, due to the copyright warnings posted on the page. It would seem to make sense to type the substantiation in Word and then copy and paste it into the field. That is only slightly better than directly typing the information in that small field.

Text formatting is also lost between Word and Terra. There is almost no ability to format text in the substantiation, and it is no better than an old-fashioned typewriter. In some respects it is worse, because it usually runs paragraphs together. There may be a carriage return, but if double spaces between paragraphs were on the original document, they may or may not be there in Terra.

Terra provides a weak search tool for the public, and the staff search tool is only slightly more powerful. There is no reason that the public can’t at least have access to the staff search tool. Most of the search capability that FileMaker provided is gone.

Terra does a poor job of printing public inputs and public comments. The first page may have a title and frame around the page; however, this page will be mostly blank. The real information doesn’t appear until the second page. This doesn’t happen every time, but it happens often enough to be annoying and there is never a warning when it will occur.

One of the goals expressed in Terra’s early development was that at the end of the process, we could just “push a button to generate the first and second draft reports.” We are a long way from that, because there is another step that is largely invisible to the public. The NEC document needs to be modified in Arbortext, an XML editing program.

When I was at NFPA, I taught many online classes in how to use Terra. Now that I am on this side, I am experiencing it firsthand. It is easy to decide that those having problems are not tech-savvy. However, even the most experienced find it frustrating.

The tool is a noble effort to improve the process. Providing online access was important. However, improvements are still needed: a better text editor in the standards text and substantiation fields, a better search capability and the printing needs to be improved to eliminate blank pages.

About the Author

Mark Earley

Mark Earley, P.E., is an electrical engineer. Retired from the National Fire Protection Association, he was secretary of the National Electrical Code Committee for 30 years and is president of Alumni Code Consulting Group.

Stay Informed Join our Newsletter

Having trouble finding time to sit down with the latest issue of
ELECTRICAL CONTRACTOR? Don't worry, we'll come to you.