The Humble Programmer – Edsger W Dijkstra

I first heard of Edsger W Dijkstra in the context of agile programming.I was having a discussion regarding agile programming with some friends and explaining Test Driven Development and the concept of first creating tests that can prove show the correctness of the code before writing the code, when a friend mentioned that this sounded a lot like some of the arguments put forward by Prof. Dijkstra in his Turing award lecture in 1972. I found that hard to believe, after all, if this was known in 1972 then why is it only becoming popular now ?

So I started looking up Edsger W Dijkstra and realized that this man was one of the pioneering giants of software programming. He is the father of structured programming and one of the guiding heads responsible for much of the way we program computers today. There is a lot written about him all over the place – I shall focus on his Turing award lecture, that was titled “The Humble Programmer“. In this lecture, Prof. Dijkstra puts forth six arguments on the way software programming should be done. On reading these six arguments I cannot help but feel that this lecture was one of the main inspirations used by the authors of the agile programming movement and design patterns community.

The six arguments put forward in the lecture are as follows –

1. “A study of program structure had revealed that programs —even alternative programs for the same task and with the same mathematical content— can differ tremendously in their intellectual manageability. A number of rules have been discovered, violation of which will either seriously impair or totally destroy the intellectual manageability of the program.I now suggest that we confine ourselves to the design and implementation of intellectually manageable programs. The programmer only needs to consider intellectually manageable programs, the alternative alternatives he is choosing from are much, much easier to cope with.”
2. “As soon as we have decided to restrict ourselves to the subject of intellectually manageable programs, we have achieved once and for all a drastic reduction of the solution space to be considered. This argument is distinct from argument 1.”
3. “If one first asks oneself what the structure of a convincing proof would be and having found this, then construct a program satisfying this proofs requirements, the these correctness concerns turn out to be a very effective heuristic guidance. By definition this approach is only applicable if restrict ourselves to intellectually manageable programs.”
4. “The only mental tool by which a very finite piece of reasoning can cover a myriad of cases is called an “abstraction”. There are number of patterns of abstraction that play a vital role in the construction of programs. Knowledge of these patterns of abstraction are essential.”
5. “A programmer is fully aware of the limited size of his own skull; so he approaches the task of programming in full humility and avoids clever tricks.”
6. “The only solutionproblems we can solve in a satisfactory manner are those that finally admit a nicely factored solution.”

When you go through these arguments you see the seeds for the various movements in programming software today –

• Arguments 1 and 2 are the foundation of principles like KISS (Keep it Simple and Stupid) and YAGNI (You Ain’t Gonna Need It)
• Argument 3 forms the basis of efforts like  Test Driven Development and the Design By Contract.
• Argument 4 leads us to Design Patterns.
• Argument 5 and 6 preaches humility in programming, the use of abstraction to write readable well factored programs – beautiful code

I really enjoyed reading his lecture – I have the lecture here (The_Humble_Programmer)  if you want to read it. He must have been an extremely engaging speaker – a lot of his quotes are available here.

Till next time – Happy Programming !

Update: I have made a couple of corrections based of some of the comments here.  When I wrote that argument 3 is the basis for TDD I meant that in the lecture Dijkstra talks about first finding the structure of a proof and then constructing the program satisfying the proofs requirement. This is similar to the TDD approach of first writing a test and then writing code that satisfies the test.