I was re-reading appendix B in Alistair Cockburn’s book, Agile Software Development, 2nd edition.  He has posted the entire appendix on his own blog.

Peter Naur thinks it important to consider the sort of activity that programming is.  Because if it is misconceived, we will not be as successful at it as we could be.

… the main point I want to make is that programming in this sense primarily must be the programmers’ building up knowledge of a certain kind, knowledge taken to be basically the programmers’ immediate possession…

Naur calls this kind of knowledge a ‘theory’, in the sense that the philosopher Gilbert Ryle used the term. A theory in this sense is a kind of tacit knowledge that a person can acquire, that – here is the strange part – cannot be expressed, i.e. cannot be put down as so many rules or principles.  However, one in possession of a theory about a program can, by working closely with others, induce them to acquire a similar theory, one that is serviceable for carrying on the development of a computer program in accord with the theory of it.

What does this mean for practice?  It is often recommended that a team of programmers who have developed a program remain closely connected with it throughout its life.  In Naur’s sense, they possess a theory of the program that other people cannot acquire by reading the program source code and any amount of documentation, no matter how well written.  There will be objection to this idea.  It once was, and still is in some quarters, a standard practice to hand over a program to a maintenance team after the program sees production.  The idea is that the original designers, presumably expert developers, should move on to new projects where their skill in, shall we say ‘theory building’, can best be utilized.  Meanwhile, the maintenance team, usually comprised of members with less skill and experience than the original developers, will take responsibility for program extensions and bug fixes.  A major point of Naur’s essay is that this is misguided.  Without a period of transition, where at least some of the original developers work on the maintenance team, the group picking up a program having only the source and documentation will be trying to ‘resuscitate’ a dead program, a program whose original development team has dispersed and the theory forgotten.  They will be attempting to build a new theory of the program and how it relates to the world.  And it is almost guaranteed they will get it wrong.  This is not a diatribe against documentation.  But it must be realized that the point of documentation is to be an aid to memory in the building of a theory of the program.  Using a document alone is not sufficient to acquire an adequate theory of the program.  Getting that requires speaking directly – and at length – with someone in possession of it.

You will have to digest the Naur essay and see if you agree or not.  I believe that Naur is right, and that a tacit knowledge, a theory of a program and its relation to the world (domain) is created by the programmer.  This is the real activity of what we call computer programming.  It is about gaining an understanding of a certain kind and becoming an expert in that program and its domain.  This turns the programmer, as person, into a value asset for the employer.  Naur concludes that as such, programmers should be recognized for what it is they actually do, which is to become knowledgeable.  This, and not the texts they produce as source code and documents, constitutes their real contribution.  This is why programmers should be kept together as working teams and kept working on software they have developed.  Because they are the ones in possession of the program’s theory and cannot give it easily over to others, but only over time in working with new team members.