As you read this column, be sure to look carefully. An error exists somewhere in the first paragraph. Some readers may be able to find it just by looking. Others might be forced to resort to a spell checker.
While you ponder that riddle, let me move on. This simple exercise serves to point out a very important fact. A designer's thought process, intent, and inherent intuition shouldn't be taken lightly.
Consider for a moment that the design process has and will continue to grow increasingly complex. Overworked engineers are hard-pressed to remember what they ate for lunch, let alone which segment of code is responsible for a particular function. Documentation helps—that's assuming there is documentation and that it has been done halfway decently. Keeping track of and verifying a design is usually a difficult process.
Designers aren't left to fend for themselves. On the contrary, many vendors now offer tools to manage data manipulation and design verification. It's these sorts of tools that started me thinking about those fabulous, "can't live without 'em" spell checkers.
It's like this. Even the best spell-checker can't anticipate and account for all language and sentence structure possibilities. That's because while written language abides by certain rules, there are always exceptions to the case. A spell checker, therefore, could register as an error something that is nothing more than its own misunderstanding of a particular word usage. That does not make what you wrote incorrect. It simply means that the tool isn't smart enough, and perhaps never will be smart enough, to account for all language variations.
This analogy holds true for design code. There are certain rules that must be followed when writing the code. But there are exceptions.
Design tools can check the correctness of the code against the rules governing the standard language. They also can perform various verification tasks to tell you if a problem exists. Just like spell checkers though, these tools aren't 100% accurate. Often, they generate false errors that must be investigated further.
Some of the tools will quickly tell you whether the error is real or false. Others require that the designer wade through this process manually. In the latter case, what becomes crucial is how quickly and easily the tool can be manipulated to help you determine the real errors. It can be a slow and painstaking process.
You may wonder what the point is in all this. Perhaps it's simply worth noting how important it is to understand the nature of tools that produce false errors. And, making sure you realize which type of tool you have before you invest in it.
Yet, at the same time, I feel compelled to tell you to trust your own intuition. Yes, designs are complex and a lot of data must be managed. But, you are the design's creator. At some gut level you must have a feeling for what you have done and why. I don't care how smart design tools are. They will never be able to replicate that level of understanding.
I guess the bottom line is to use these tools for what they are—tools—and not as a crutch! Regardless of whether or not your tool of choice tells you a problem exists, if your intuition and years of experience hint at the opposite answer, question the tool's result.
Hey, did you ever find that error? No! Maybe that's because there wasn't one. How many of you read the first paragraph more than once, or even typed it into your computer and ran the spell-check function—all because I told you there was an error. I guess you should have trusted your own intuition! Either way, write to me and let me know.