40 years later, are Bentley's "Programming Pearls" still relevant?

In September 1985 Jon Bentley published Programming Pearls, a collection of aphorisms designed to reveal truths about programming. Forty years later, after several revolutions in the field, surely these are obsolete? Depressingly, nearly everything in here remains relevant. Straight off the bat a winner from Ken Thompson: when in doubt, use brute force. Almost all problems are solvable through brute force. Once you know it can be done, then see how it can be done better. Roy Carlson: the sooner you start to code, the longer the program will take. Right in the truth. Much like the woodsman who spends his time sharpening his axe, diving into code is probably the least efficient way to create something.

Peter Halpern: if you can't write it down in English, you can't code it. So many bugs come from not understanding requirements of the user or customer. Details count. Very easy to go for big picture view of software, but unless all those sharp edges are filed down, code isn't going to have a happy life. Norm Schyer: if the code and the comments disagree, then both are probably wrong. Dream of self-documenting code will never be realized. Goes back to inability to properly describe requirements and inadequacies at turning those comments into code. David Tribble: a procedure should fit on a page. Amazon has Two Pizza rule defining maximum size of team. Larger and more complex something is, the more likely it is to go wrong.

Principle of Least Astonishment: make a user interface as consistent and as predictable as possible. Why isn't this hammered into every programmer? Today's tools are filled with hidden UI gestures, random menus, complete disregard for user's time. Vic Vyssotsky: twenty percent of all input forms filled out by people contain bad data. Mike Garey from the future: eighty percent of all input forms ask questions they have no business asking. Mark Donner on bugs: 80 percent are syntax errors, of remaining 20 percent 80 percent are trivial logical errors, of remaining 4 percent 80 percent are pointer errors, and remaining 0.8 percent are hard. Syntax errors are rarer now with IDEs. Logic errors still plague us. Pointer errors eradicated unless working at lowest levels. Number of hard bugs probably higher due to complex interaction of multiple libraries and systems.

Tom Cargill Rule of Credibility: first 90 percent of code accounts for first 90 percent of development time, remaining 10 percent accounts for other 90 percent. Agile somewhat dimmed potency, but hard to escape Zeno's Paradox. May Shaw: less than 10 percent of code has to do with ostensible purpose of system, rest deals with input-output, data validation, data structure maintenance, other housekeeping. How many times have you installed simple program only to see it pull in every dependency under the sun? Fred Brooks on prototypes: plan to throw one away, you will anyhow. Craig Zerouni with double-tap: if you plan to throw one away, you will throw away two. Furious activity is no substitute for understanding. Always tempting to rush in pell-mell but that's poor use of time. Majority of disagreements are minor quibbles. While disk-bound I/O is rarely a problem, network latency has replaced it as main cause of delays. Fixed some things, but many irrevocably tied to human condition.