This is the third edition of Code Reads, a weekly discussion of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s the full Code Reads archive.
This will be a briefer entry than I originally planned. I’ve fallen behind a bit this week! So rather than post about all three essays I mentioned last week, I’m going to confine myself to “The Humble Programmer,” Edsger Dijkstra’s Turing Lecture, delivered in 1972.
In “The Humble Programmer” (text, PDF) Dijkstra offers an overview of the programming universe as he saw it in 1972. In the ’50s and early ’60s, programming pioneers struggled against the “painfully pinching shoe” of inadequate equipment. Then they got the more powerful machines they longed for. “But instead of finding ourselves in the state of eternal bliss of all progamming problems solved,” Dijkstra wrote, “We found ourselves up to our necks in the software crisis!” The problem was that the upward curve of ambition driven by new hardware capacity outran the improvements in software:
As the power of available machines grew by a factor of more than a thousand, society’s ambition to apply these machines grew in proportion, and it was the poor programmer who found his job in this exploded field of tension between ends and means. The increased power of the hardware, together with the perhaps even more dramatic increase in its reliability, made solutions feasible that the programmer had not dared to dream about a few years before. And now, a few years later, he had to dream about them and, even worse, he had to transform such dreams into reality!
From its title to the repetition of phrases like “the poor programmer” to its references to “the intrinsic limitations of the human mind,” the essay presents a chastened vision of the human capacity to create software: the programmer, Dijkstra says, must be “fully aware of the strictly limited size of his own skull.”
Despite this deliberate lowering of the eyes, Dijkstra does offer a not-so-humble prediction: that, “well before the seventies have run to completion, we shall be able to design and implement the kind of systems that are now straining our programming ability, at the expense of only a few percent in man-years of what they cost us now, and that besides that, these systems will be virtually free of bugs.” The first prediction essentially came true, as the programming field managed to continue to produce increasingly ambitious systems. The second, however, is still nowhere in sight.
Dijkstra presents six arguments for why his prediction is technically feasible, built on the proposition that we should “confine ourselves to intellectually manageable programs.” This sounds sensible, but it will always run up against the nature of software innovation, which always pushes us to try new stuff at the edge of what’s possible, because that’s what’s worth doing.
Mixed in among his other arguments is a prophetic description of a test-first process that developers today would call “test-driven development” (Roy Osherove comments on this as well), and a warning against the sort of language or toolset that invites “clever tricks” (or “the one-liners” — showy stunts aimed at impressing fellow programmers).
There’s something pleasing about the down-to-earth way Dijkstra expresses the strangely-bound-together optimism and pessimism of his world-view, in which the trajectory of software is always progressive — but that very progress is what keeps the process from getting any easier:
Programming will remain very difficult, because once we have freed ourselves from the circumstantial cumbersomeness, we will find ourselves free to tackle the problems that are now well beyond our programming capacity.
I wonder if other readers will have the reaction I had to Dijsktra’s argument that bugs are simply not to be tolerated: “If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with.” If he means, it’s easier to fix errors at the time you make them rather than much later, that makes some sense; but it sounds more like “you simply shouldn’t make any mistakes in the first place.” That would be nice. But it doesn’t sound like the real world programmers everywhere have experienced, all the way back to that seminal moment in the ’40s when Maurice Wilkes realized he would spend a “large part of his life” correcting his own mistakes.
(For a fascinating contemporary argument on why software producers consciously ship products with bugs, Eric Sink’s article is worth a look.)
Post Revisions:
There are no revisions for this post.