One of my favorite quotes about software development is that “software development is not a product-producing activity, it is a knowledge-acquiring activity” (Phillip G. Armour, “The Five Orders of Ignorance”, CACM 10/2000).

One of the consequences is that there are fundamentally two types of “bugs” or defects: (1) “we” know how it should work, but have messed up reflecting that knowledge in the software, and (2) the software accurately reflects our knowledge, but our knowledge is in some way “defect”. Plus, there is another one: Practically all relevant software is developed in teams, and there is a chance for misunderstandings between the individuals comprising the teams.

A lot has been thought and written and invented around getting rid of these misunderstandings. So far, none of it works reliably: at the very least, the task at hand and the people on the team should determine the choice of method (and, especially in large corporations, doesn’t).

I’d like to take a different angle to that task for a moment and think about it from the point of view of knowledge elicitation and transmission. For most working software projects, I have seen that they are driven by people understanding each other, not by people following process. It is almost like back in the days when mankind was still following oral traditions.

Do get me right: I’m not against writing things down, not at all. I’ve been the faithful biographer to quite a few projects, and these “project biographies” do have their importance. It’s just that, on the grander scale, a project is more likely to work when people are talking just to each other when they just send written tasks back and forth.

Ultimately, the oral tradition and the project biography have to complement each other, but for the next few blog posts, I’d like to focus on the “oral tradition”.