In Memoriam: Peter G. Neumann
One of the great applied computer scientists, Peter G. Neumann, died on May 17. There have already been obits published, including in the New York Times. I knew Peter since at least 1992, and I’m honored that he considered me one of his colleagues and friends, even staying overnight at my house once. And that in itself shows another facet of his personality—while he had very strong opinions on technical subjects (and other things—for example, he did not think that Shakespeare wrote the the plays generally attributed to him), and was of course exceedingly accomplished (as the other obits made clear) in many fields, he was at heart someone who preferred simplicity even in his personal life. He was always happier staying with friends instead of in hotels, and preferred simpler restaurants to fancy ones. Simplicity, always.
What I really want to talk about, though, is that Peter, more than almost anyone else I’ve known, understood and strongly believed in the systems nature of problems. That is, there’s not one cause to a problem; everything, including the humans involved, interact.
Take, for example, buffer overflows, long a security scourge on the Internet. Is it the fault of the programmers? I knew someone who, 40 years ago (and several years before the Internet worm made the problem obvious), wrote a string-handling library before embarking on a text-heavy, security-sensitive program, because he felt that he’d never get things right otherwise. He was a very good programmer—is that the solution?
Maybe the problem in the C language. Lots of people have criticized C for its lack of memory safety, but in fact that’s an implementation and OS issue—exceeding array bounds is left undefined by the standard, which means that compilers are free to add array bounds metadata and to check it on array references. That requires different pointer implementations, which destroys ABI and OS compatibility. It’s also slower, because of the need to fetch and compare against the bounds on all references, so maybe we should blame compilers that don’t optimize enough or hardware that doesn’t make such checks efficient. (Hardware array bounds checking? The Burroughs B5000 had it in 1962.)
Take your choice, then: the person, the language, the compiler, the OS, or the hardware? The real answer is that it’s a system problem: all of these pieces interact.
This is what Peter really understood—and taught others. Go back and read the RISKS Digest or the Inside Risks columns and you’ll see what I mean: a very high percentage of the failures described, including of course some of my favorite ones, happened because of multiple interacting issues. It’s why he was a fan of the famous Einstein quote, “Everything should be as simple as possible—but no simpler” (and Peter got to discuss that one morning with Einstein himself!). But pay special attention to the second clause: “but no simpler.” Peter was a fan of simplicity, but he realized that some things were inherently complex. The real trick, and one fiendishly difficult to pull off, is to eliminate the unnecessary complexity. But you can’t eliminate complexity by changing one part of a system, because they all interact. He understood that, both the problem of complexity and the difficulty in eliminating it. Too few people do.
Peter Neumann will be missed. May his memory be for a blessing.
