Save Me from Cleverness

By Peter Coffee  |  Posted 2006-05-15 Print this article Print

Opinion: Too many options are too hard to find and control.

Programming guru Brian Kernighan has famously said that debugging code is twice as difficult as writing it—and, he said, it follows that, "If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." Id generalize this to two principles that should be followed by anyone who buys, builds or uses complex and powerful systems: Leave half of what you have in reserve, and assume below-average cleverness.

I first saw Kernighans warning in the 1988 paperback reprint of his 1974 McGraw-Hill book (with P.J. Plauger), "The Elements of Programming Style." Many people have been quoting his comments this May in the context of a flaw found in March in a widely used implementation of the X Window System, an MIT-originated protocol for cross-platform GUI construction.

Despite the mocking label of "the first fully modular software disaster" seen on a poster at one X Window conference, X Window has been a pathway to portability for any number of useful tools that might otherwise be available only on Windows. For example, the Macintosh version of the SlickEdit programmers editor runs on Macs by means of the X Window implementation packaged with OS X.

X Window is an open-source project (, with plenty of eyes scanning its reference implementation and other implementations for bugs or vulnerabilities. A Department of Homeland Security audit (your tax dollars at work) found the flaw that provoked this months comments on cleverness—and many have since made the point that this demonstrates a key virtue of open-source efforts.

In our own eWeek story on how the vulnerability came to light (see "Govt-funded security audit flags X11 vulnerability" at, the chief technical officer of the DHS contractor doing the audit described the cause as "something as seemingly harmless as a missing closing parenthesis." Thats not quite correct, and the problem would have been found much sooner if that had been the case.

Missing punctuation will generally result in a programs failing to compile, let alone run—although substituting one punctuation mark for another can be devastating, as in the legendary case of the FORTRAN code that disrupted a NASA mission when a period replaced a comma.

In the case of the recently discovered X Window flaw, the missing marks were a pair of parentheses, creating a classic case of the machine doing exactly what it was told instead of what was wanted. In two places where the code should have said "geteuid()" (call function "geteuid" with no arguments and return the result), there instead appeared "geteuid" (return the memory location of the "geteuid" code).

The error would have been caught if the C programming language distinguished between the concepts of zero (a number) and null (absence of a value), but it does not. The convenience of using "0" for both, and the cleverness of letting a functions name serve as both verb of invocation and noun of code location, are defining features of the C language—of which cleverness critic Kernighan, ironically, was one of the main designers.

Famously terse, C is not a language where youd expect to find something as verbose as Visual Basic .Nets "AddressOf" operator, which appears in statements such as "AddHandler Button1.Click, AddressOf Button-ClickHandler" (an example from Microsoft documentation) and makes the codes intention perfectly obvious. Another good rule to remember is that most code will be written only once but read many times, and that its more important for a language to be easy to read without ambiguity than to be easy to write with few keystrokes.

But coders are not the only ones who are ill-served by systems designed to treat almost every possible input as a legitimate (if, perhaps, obscure) command. Try to find a keystroke in an application like Microsoft Word that doesnt have some function, changing the editing sessions behavior without telling the user how or why.

Real systems and real users dont do well when balanced on the sharp edge of making too many things too easy to do, in ways that are often too difficult to see.

Peter Coffee can be reached at For reader response to this column, click here. Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
Peter Coffee is Director of Platform Research at, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel