Design Rule #005—Follow the Specifications

Years ago, when I was the Technical editor of CADENCE magazine, reviewing the latest hardware and software products every month, I came to the conclusion that engineers don’t read specs.

The conclusion was not based on talking with any engineers or product managers about the subject, just on my own observations of comparing product features—especially those relevant to interoperability—against the actual specifications (or excerpts) I could get my hands on.

I have held this conviction ever since, and although I don’t get to test it frequently, I see ample evidence of it, and whenever I do get the chance to talk to engineers about specs, they always uphold my maxim.

The widely practiced alternative is to copy how another few products have implemented the specification. But since none are complete, only parts of the specification get implemented, and not always completely or correctly.

The natural result is that the products are less capable and far less interoperable than the specification authors intended.

This hurts the consumers of the product, and it hurts the company who made it, because they have failed to deliver a complete product that operates well—inevitably leading to disappointment and frustration, and fewer sales.

I was reminded of this yesterday when I had a new batch of personal business cards printed, with a rectangular Data Matrix barcode, holding the URL to my vCard.

But when I fired up my half-dozen iPhone 2D barcode scanners, none of them succeeded.

Perplexed, I tried them on an older card, with a much larger Data Matrix that held the whole vCard. Success! Even though it was blurry and I had forgotten the white space between fields, at least it decoded.

After much experimentation and tweaking the zoom setting of several apps that used the same engine, I failed completely. Trusty-old RedLaser, which I swear had worked on this very code before, failed, too. Worse, when I read their post on supported code types, it was clear they had deliverately disabled all Data Matrix decoding (not just rectangular ones) because they “aren’t associated with store products.” Funny, though, I have a tube of Crest with a Data Matrix, so this isn’t really accurate.

I searched online for references to one that might succeed, and was reminded of NeoReader, which I had once used, then discarded for some reason.

Of the seven 2D barcode scanners now on my iPhone, NeoReader is the only one that can scan my business card. Alas, neither it nor the iPhone can extract the contents of that URL and feed them to the Contacts app, as would seem natural.

A good amount of frustration was caused for me simply because the developers of these apps either didn’t read or read and chose not to fully implement well-known specifications:

• The international ISO standard for Data Matrix
• The RFC for vCard
• The international GSN standards which call for support of Data Matrix on store products

I’m convinced the only way this sorry state of affairs will improve is when universities start teaching engineering students how to find and read specifications.

A whole class on this subject for mechanical, electrical, and software engineers, architects, and other designers would be a great idea (although it alone would not be enough). The first step is for the engineering libraries to keep the more important standards on the shelves. (Many, though not all, are too expensive for students to afford on their own.)