The humble programmer

Reading the ACM Turing award lectures really opened my jaw the other day.

In his lecture, "The Humble Programmer", Edsger W Dijkstra is promoting the kind of ideas that even today a lot of developers that I know don't even try to implement. Mind you, this lecture is from 1972, 30 years back!

"Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give proof for its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmers burden. On the contrary: the programmer should let correctness proof and program to go hand in hand..."

Test driven development is all about creating a small test, see it fail, make it work, refactor and move on to the next test. Proof and program hand in hand. I am amazed that a person was able to realize such a great concept reaching so far into the future.

Here are some more great quotes from this lecture:

"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.."

This is not a derogatory remark. It means that, especially these days, as the size of the systems we work on so hard is so big, we need to know our limits and act accordingly. Biting off more that you could chew mentally can lead to some disastrous results. Test driven development is all about taking very small bites and processing them as you go. This way, even the most complex task begins with one small test.

"...a specific phenomenon occurs that even has a well established name: it is called "the one-liners".It takes one of two different forms: One programmer places a one line program on the desk of another and either proudly he tells what it does and adds the question "Can you code this in less symbols?" -- as if this were of any conceptual relevance!-- or he just says, "Guess what it does!" from this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation to some of its appeal, viz. to those who like to show how clever they are,I am sorry,but I must regard this as one of the most damning things that can be said about a programming language."

Sounds familiar? 

Here's the closing:

"...We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers. "

Simply amazing. I've read these words in many other books, but reading them in this lecture is like finding out the origins of our habits. I get context of where I am in the history of development, how "not new" all the ideas I consider to be breakthrough really are. Indeed, a mind and jaw opener.

Published Wednesday, January 21, 2004 6:49 PM by RoyOsherove
Filed under: ,

Comments

Wednesday, January 21, 2004 11:59 AM by AndrewSeven

# re: The humble programmer

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
(Edsger Dijkstra)


http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html

Wednesday, January 21, 2004 12:06 PM by Roy Osherove

# re: The humble programmer

Yep. That's always a great quote :)
Wednesday, January 21, 2004 1:30 PM by Ian Griffiths

# re: The humble programmer

It's fascinating that the last time I saw someone cite the first paragraph you quote there, they were using it to argue about the *deficiencies* of unit testing!

I'm a huge fan of test-driven development - I long since got to the point where I feel wrong if I try to write code before I write a test.

However, I don't believe that this approach addresses the fundamental problem that Dijkstra refers to. Whether you write your tests first or last, if tests are all you have, you have no way of knowing whether your program has problems you simply haven't written tests for.

Dijkstra seems to be talking about constructing proofs of correctness, which is a very different way of building code from test-first development.
Wednesday, January 21, 2004 7:55 PM by Shane King

# re: The humble programmer

As Ian says, you're totally distorting Dijkstra's words.

He says "it [testing] is hopelessly inadequate for showing their [bugs] absence". How you can then go on to conclude that Dijkstra is in support of test driven development is beyond me. You're just hearing what you want to hear if you draw that conclusion.

If anything, Dijkstra seems to be advocating formal methods, which is something that is a 180 degree turn-around from the agile methods most advocates of test driven development believe in.
Wednesday, January 21, 2004 8:10 PM by AndrewSeven

# re: The humble programmer

I've just started the move to test driven, but I notice that I have always done some things in a test-oriented way.

I talk about it at work and I get stranger looks than I did when I started talking about .Net ;)

Build when you expect an error to be sure the error is where you expect it to be.
Call code you expect to fail for the same reason.
Use functions that don't exist yet so I can see what to call them...

I think Dijkstra is just using different terms, he is talking about an itimate realationship between proof(test) and functionality.

There are almost always more tests that will make the functionality fail, but without any tests, you can't be sure it does what you think.

I find it quite interesting how well Dijkstra's ideas resonate with XP aproaches.


Thursday, January 22, 2004 4:09 AM by Roy Osherove

# re: The humble programmer

Shane: Distorting? hardly. Dijkstra's message was that tests *before* or *during* the program are *part* of how we should program. The fact that Dijkstra realized that testing will never be enough to help us conclude that there are no bugs does not subtract from the realization that testing *after* the programming is much less useful that before the actual work. Yes, this realization is part of 6 simple rules that Dijkstra portrays in his lecture. The basic theme there is that programs should be limited to intellectually manageable programs. The realizations that testing before coding helps you mentally with creating the program is one of these corner stones.
Thursday, January 22, 2004 7:45 AM by SBC

# re: The humble programmer

I like the comment about knowing the limitation of one's skull.. :-)
I recall recent postings about 'complexity & sophistication' - http://weblogs.asp.net/sbchatterjee/archive/2003/11/09/36583.aspx
Thursday, January 22, 2004 8:10 PM by Leon Bambrick

# re: The humble programmer

classic document. thanks for pointing it out.

Thursday, October 19, 2006 2:46 AM by Scott Rosenberg's Wordyard » Blog Archive » Code Reads #3: Edsger Dijsktra's "The Humble Programmer"

# Scott Rosenberg's Wordyard » Blog Archive » Code Reads #3: Edsger Dijsktra's "The Humble Programmer"

PingBack from http://www.wordyard.com/2006/10/18/dijsktra-humble/

Thursday, October 19, 2006 9:33 AM by Curt Sampson

# Testing vs. Formal Methods

To interpet argument three as promoting, rather than arguing against, TDD is a completely backwards interpretation. Dijsktra is clearly talking about using proofs (formal methods) instead of testing; TDD is testing, not any sort of proof at all. That the tests are written first or last is of no consequence; the tests still cannot prove the absence of all bugs in a particular piece of code. (Well, they could in the case where they test every possible combinations of input and ouput, constituting some sort of a proof through exhaustive enumeration, but that's not practical.)