A few days ago I asked you to think about how to define your job as a software developer in a single sentence. This question is highly correlated to the question of what’s programming.
That’s why an article on the matter was pointed to me on twitter in response to my tweet on software developer’s job.
Looking for Naur’s programming as Theory building will lead you to this article.
It was written by Peter Naur (the one from the Backus-Naur Form, aka BNF programming language syntax notation) in 1985, and it is so far one of the most comprehensive texts on what’s programming I had the chance to read.
To quote him, a motivation “of the presentation is a conviction that it is important to have an appropriate understanding of what programming is. If our understanding is inappropriate we will misunderstand the difficulties that arise in the activity and our attempts to overcome them will give rise to conflicts and frustrations.”
I could hardly agree more.
Programming and the programmers’ knowledge
The main point of the article is that a programmer (and her team) somehow build a theory of the program when working on software, and that this knowledge cannot be totally embedded in documentation and/or code quality. Actually, the fact that different developers will build different theories explain why we will always find a codebase we have to maintain from someone else “bad”.
This is independent of the code quality or documentation unfortunately.
“The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaptation, modification, and correction of errors in them, is essentially dependent on a certain kind of knowledge possessed by a group of programmers who are closely and continuously connected with them.”
How to treat the programmer
One of the main impacts of such a view is that developer cannot be the disposable we would like them to be in an industrial process. Quite the opposite, they will appear as key part of any success stories in the software industry.
“At the level of industrial management these views support treating programmers as workers of fairly low responsibility, and only brief education. On the Theory Building View the primary result of the programming activity is the theory held by the programmers. Since this theory by its very nature is part of the mental possession of each programmer, it follows that the notion of the programmer as an easily replaceable component in the program production activity has to be abandoned. Instead the programmer must be regarded as a responsible developer and manager of the activity in which the computer is a part.”
What’s a dead program
If we acknowledge that the team building the product is so important, it follows that the life and death of a program is not defined by the fact that it runs in production, but by life and death of the team building it. From that we can suggest that methods like pair and mob programming are must have for a long living program, because it will help the theory of the program to be distilled continuously through the team, and it will address the training of newcomers to know the existing theory.
“The death of a program happens when the programmer team possessing its theory is dissolved. A dead program may continue to be used for execution in a computer and to produce useful results. The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered. Revival of a program is the rebuilding of its theory by a new programmer team.”
[…]
“What is required is that the new programmer has the opportunity to work in close contact with the programmers who already possess the theory, so as to be able to become familiar with the place of the program in the wider context of the relevant real world situations and so as to acquire the knowledge of how the program works and how unusual program reactions and program modifications are handled within the program theory.”
And much more…
From my perspective, this article also gives insights about writing small replaceable features instead of huge monolithic one, on the importance of unit tests and on the reason why software development can’t be handled like an industrial process.
But as Florent Pellet recalls me recently, it’s always dangerous to interpret past writing with our current context and understanding.
Still, this paper is older than me, and it seems to me that it embedded many visionary wise knowledge that is absolutely not mainstream todays.
Do you have the same feeling about it?