The following is a parable about the difference between theory and practice, which Michael Oakeshott frames as the difference between technical and practical knowledge, found as a footnote in Michael Oakeshott's essay Rationalism In Politics.  I find that it has some bearing, which I will discuss in the near future, to certain Internet debates about pedagogy and software programming:

"Duke Huan of Ch'i was reading a book at the upper end of the hall; the wheelwright was making a wheel at the lower end.  Putting aside his mallet and chisel, he called to the Duke and asked him what book he was reading.  'One that records the words of the Sages,' answered the Duke.  'Are those Sages alive?' asked the wheelwright.  'Oh, no,' said the Duke, 'they are dead.'  'In that case,' said the wheelwright, 'what you are reading can be nothing but the lees and scum of bygone men.'  'How dare you, a wheelwright, find fault with the book I am reading.  If you can explain your statement, I will let it pass.  If not, you shall die.'  'Speaking as a wheelwright,' he replied, 'I look at the matter in this way; when I am making a wheel, if my stroke is too slow, then it bites deep but is not steady; if my stroke is too fast, then it is steady, but it does not go deep.  The right pace, neither slow nor fast, cannot get into the hand unless it comes from the heart.  It is a thing that cannot be put into rules; there is an art in it that I cannot explain to my son.  That is why it is impossible for me to let him take over my work, and here I am at the age of seventy still making wheels.  In my opinion it must have been the same with the men of old.  All that was worth handing on, died with them; the rest, they put in their books.  That is why I said that what you were reading was the lees and scum of bygone men.'"

-- Chuang Tzu

Science is all about making proposals that can be tested (especially after Karl Popper's formulation of the Falsifiability Criterion), and then undergoing the experience of having that proposal rejected.  This is the essence of any successful process -- not that it eliminates errors altogether, but rather that it is able to make corrections despite these errors so that the target need never shift.

Professor Alain Connes recently gave his opinion of Xin-Jing Li's proof for the Riemann Hypothesis -- a proof which relies in part on Professor Connes' work --  in a blog comment to his own blog (by way of Slashdot):

 

Self-correcting extends to other professions, as well.  Scott Hanselman recently posted to correct an opinion he discovered here which he felt required some testing.  Through his own tests, he discovered that nesting a using directive inside a  namespace declaration provides no apparent performance benefit over placing it outside the namespace.

This leads him to draw these important lesson:

 

The sentiment recalls Ralph Waldo Emerson's memorable words:

 

 

A similar sentiment is expressed in Hobbes' Leviathan, though with a wicked edge:

 

 

We find it again expressed in Descartes' Discours de la méthode. Descartes, it might be remembered, occasionally exchanged letters with Hobbes:

 

 

Both Hobbes and Descartes formulate their defense of common sense somewhat ironically.  In a recent post, Steve Yegge takes out the irony (or perhaps takes out the kernel of truth and leaves nothing but the irony) in his argument against Joel Spolsky's widely aknowledged criteria for a desirable employee: "smart, and gets things done."

According to Yegge, the crux of the problem is this:

 

 

And yet the self-correcting process continues, on the principle that we are all smart enough, collectively, to solve our problems in the aggregate, even if we can't solve them as individuals.

Presidential candidate Barack Obama recently held a news conference to correct a misunderstanding he had made a few hours earlier about his stance on the Iraq War.  According to CNN:

 

 

This is, of course, merely a blip in the history of self-correction.  A more significant one can be found in Bakhtin's attempt to interpret the works of Rabelais, and to demonstrate (convincingly) that everyone before him misunderstood the father of Gargantua. 

Bakhtin's analysis of Rabelais in turn brought to light one of the great discoveries of his career: The Carnival -- though a colleague once found an earlier reference to the concept in one of Ernst Cassirer's works.  Against the notion of a careful and steady self-correcting mechanism in history, Bakhtin introduced the metaphor of the Medieval Carnival:

 

 

The Carnival serves to correct inequalities and resentments in society and its subcultures not by setting it upon a surer footing, but rather by affording us an opportunity to air our grievances publicly in a controlled ceremony which allows society and its hierarchical institutions to continue as they are.  It is a release, rather than an adjustment.  A pot party at a rock festival rather than a general strike.

As for the Internet, it is sometimes hard to say what is actually occurring in the back-and-forth that occurs between various blogs.  Have we actually harnessed the wisdom of crowds and created a self-correcting process that responds more rapidly to intellectual propositions, nudging them over a very short time to the correct solution, or have we in fact recreated the Medieval Carnival, a massive gathering of people in one location which breaks down the normal distinctions between wisdom and folly, knowledge and error, competence and foolhardiness? 

The company I am currently consulting with uses Scrum, a kind of Agile methodology.  I like it.  Its main features are index cards taped to a wall and quick "sprints", or development cycles.  Scrum's most peculiar feature is the notion of a "Scrum Master", which makes me feel dirty whenever I think of it.  It's so much a part of the methodology, however, that you can even become certified as a "Scrum Master", and people will put it on their business cards.  Besides Scrum, other Agile methodologies include Extreme Programming (XP) and the Rational Unified Process (RUP) which is actually more of a marketing campaign than an actual methodology -- but of course you should never ever say that to a RUP practitioner.

The main thing that seems to unify these Agile methodologies is the fact that they are not Waterfall.  And because Waterfall is notoriously unsuccessful, except when it is successful, Agile projects are generally considered to be successful, except when they aren't.  And when they aren't, there are generally two explanations that can be given for the lack of success.  First, the flavor of Agile being practiced wasn't practiced correctly.  Second, the agile methodology was followed too slavishly, when at the heart of agile is the notion that it must be adapted to the particular qualities of a particular project.

In a recent morning stand up (yet another Scrum feature) the question was raised about whether we were following Scrum properly, since it appeared to some that we were introducing XP elements into our project management.  Even before I had a chance to think about it, I found myself appealing to the second explanation of Agile and arguing that it was a danger to apply Scrum slavishly.  Instead, we needed to mix and match to find the right methodology for us.

A sense of shame washed over me even as I said it, as if I were committing some fundamental category mistake.  However, my remarks were accepted as sensible and we moved on.

For days afterward, I obsessed about the cause of my sense of shame.  I finally worked it up to a fairly thorough theory.  I decided that it was rooted in my undergraduate education and the study of Descartes, who claimed that just as a city designed by one man is eminently more rational than one built through aggregation over ages, so the following of a single method, whether right or wrong, will lead to more valid results than philosophizing willy-nilly ever will.  I also thought of how Kant always filled me with a sense of contentment, whereas Hegel, who famously said against Kant that whenever we attempt to draw lines we always find ourselves crossing over them, always left me feeling uneasy and disoriented.  Along with this was the inappropriate (philosophically speaking) recollection that Kant died a virgin, whereas Hegel's personal life was marked by drunkenness and carousing.  Finally I thought of Nietzsche, whom Habermas characterized as one of the "dark" philosophers for, among other things, insisting that one set of values were as good as another and, even worse, arguing in The Genealogy of Morals that what we consider to be noble in ourselves is in fact base, and what we consider moral weakness is in fact spiritual strength -- a transvaluation of all values.  Nietzsche not only crossed the lines, but so thoroughly blurred them that we are still trying to recover them after almost a century and a half.

But lines are important to software developers -- we who obsess about interfaces and abhor namespace collisions the way Aristotle claimed nature abhors a vacuum -- as if there were nothing worse than the same word meaning two different things.  We are also obsessed with avoiding duplication of code -- as if the only thing worse than the same word meaning two different things is the same thing being represented by two different words.  What a reactionary, prescriptivist, neurotic bunch we all are.

This seemed to explain it for me.  I've been trained to revere the definition, and to form fine demarcations in my mind.  What could be more horrible, then, than to casually introduce the notion that not only can one methodology be exchanged for another, but that they can be mixed and matched as one sees fit.  Like wearing a brown belt with black shoes, this fundamentally goes against everything thing I've been taught to believe not only about software, but also about the world.  If we allow this one thing, it's a slippery slope to Armageddon and the complete dissolution of civil society.

Then I recalled Slavoj Zizek's introduction to one of his books about Jacques Lacan (pictured above), and a slightly different sense of discomfort overcame me.  I quote it in part:

I have always found extremely repulsive the common practice of sharing the main dishes in a Chinese restaurant.  So when, recently, I gave expression to this repulsion and insisted on finishing my plate alone, I became the victim of an ironic "wild psychoanalysis" on the part of my table neighbor: is not this repulsion of mine, this resistance to sharing a meal, a symbolic form of the fear of sharing a partner, i.e., of sexual promiscuity?  The first answer that came to my mind, of course, was a variation on de Quincey's caution against the "art of murder" -- the true horror is not sexual promiscuity but sharing a Chinese dish: "How many people have entered the way of perdition with some innocent gangbang, which at the time was of no great importance to them, and ended by sharing the main dishes in a Chinese restaurant!"