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.