|
|
posted: June 25, 2016
tl;dr: Elegant simplicity can serve you well as a design philosophy...
When I got to Cornell I was already a professional programmer (i.e. had been paid to write code that was used by others), so instead of taking the 100-level “intro to programing” course I enrolled myself in CS 211, a sophomore-level class, as a freshman (I think this class has morphed into CS 2110). The best result of doing so was that I was exposed at a very early age to the design philosophy of “elegant simplicity” which was espoused by the professor who taught the course, David Gries, who at the time was also the Department Chair of the Cornell CS department. This philosophy has guided me ever since and has led to every success I’ve had in my career in technology.
Professor David Gries
“Elegant simplicity” can be stated many ways: “less is more”, “the simplest solution is the best solution”, “keep it simple, stupid”. Steve Jobs famously applied it to the products he developed at Apple, which were differentiated from the competition by the simplicity of their user interfaces and physical hardware designs. But Gries preached that elegant simplicity goes beyond the external product design to the software internals, and that the best solution to any given software problem was the simplest one. Simple software solutions are more likely to be correct, more understandable by others and hence more maintainable and longer-lived, and can be more easily enhanced and extended later.
I will never forget Gries delivering this message in the most emphatic way possible, right before the first major test in the course. The test consisted of three programming problems to which students had to code solutions in 90 minutes, writing their code in longhand into exam booklets. Gries stood before the hundred-plus students and dramatically tore a blank sheet of 8 ½” x 11” paper in half. He waved one half of the paper to the class and said: “If your answers do not fit on one half of one side of one sheet of paper, you’ve done something wrong”.
Sure enough, there were elegant, simple solutions to each of the three problems. I think the longest one took eight lines of code and the shortest was six (yes, recursion figured into one of the answers). I finished early, double checked my code, and since I was confident I had the solutions I got up to hand in my exam booklet. As I walked out I passed other students sweating bullets and hunched over their booklets, writing line after line of code: I saw 15 line solutions, 20 line solutions, and more code still being written. This shook my confidence a bit; perhaps I was missing something, and I hadn’t grasped the subtleties of the problems. But nevertheless, remembering what Gries had told us at the start, I handed in my booklet.
I aced that test and the course, which led to other academic success as well as a job with the Cornell CS department being a tutor for the intro courses and also grading programming assignments. And by applying that philosophy to the products and software that I’ve worked on in my career, I’ve built some successful systems and products that users really like and that I know work, and that have survived for many years.
The programming language in which the CS 211 course was taught (a variant of PL/I) has long ago been surpassed by other languages. Software technology has advanced tremendously with the widespread use of object-oriented programming, the Web, and the cloud, and the many orders of magnitude improvement in hardware power available to programmers thanks (primarily) to Moore’s Law. The CS 211 course itself has evolved, and certainly the physical infrastructure for CS at Cornell has improved, Gates Hall being the latest example of such. But the guiding principle of elegant simplicity remains, and the lessons I learned from David Gries (and others, but Gries was the first for me) about it are still true today.
Cornell's Gates Hall