Thoughts on Peter Naur’s Programming as Theory Building
This revolutionary paper dated back to 1985 try to answer the questions “What is the nature of programming?”.
The answer is not trivial, and the consequences related are astonishing. Here some thoughts and analysis on the topics touched in the paper.
What is the nature of programming?
In Programming as Theory Building, the very first point the paper focuses on is the nature of programming.
Naur states that programming is all about developers gathering information and insights on a real business problem and the program.
Building a theory, he says.
A mental model.
Thus the title Programming as Theory Building.
A program, a text, an artifact will be produced but only as a byproduct of the Theory Building.
If we misunderstand this point — Naur claims — difficulties and frustrations will arise.
Developers are building theory and knowledge
Note: This paragraph relates to The Theory To Be Built by the Programmer chapter in the original paper.
All the knowledge the developer has in sense of craft (knowing programming languages, patterns, designs).
All the previous experiences collected.
All the knowledge and understanding of the business problem.
This is the critical mass of information channelled by the developer to craft the program.
Throughout all this knowledge, the developer will build the theory while writing the program.
What are the effects on having the theory?
1. the dev can explain the links between program and real world
* what does the program fix or solve?
* how does the program fix or solve?
2. the dev can explain the links between parts within the program
* why each part of the program is what it is?
* how does each part relate to each other?
3. the dev can respond constructively to any demand for modification
* is it possible to implement the change or the fix?
* how long can it take?
* how to design a modification to fit in current solution?
Being able to evaluate if a new change is compatible with the current system and assess the implementation risks.
Being able to tell why about a particular part of the implemented system.
Being able to tell why that particular part is so important to solve the problem.
That is what the theory built, the mental model, the knowledge is all about.
Changes
Note: This paragraph relates to Problems and Cost of Program Modification chapter in the original paper.
It is invariably the case that a program, once in operation, will be felt to be only part of the answer to the problems at hands.
— Peter Naur
The software will be modified.
Because a new functionality to support, or because of a fix.
The very use of the software itself will inspire new functionalities.
And there is the expectation in the software industry that modify an existing solution will be cheaper and faster than creating an entirely new solution.
Is it?
Is it possible at all to modify the software?
What’s the price of changing a program without a grounded understanding?
What’s the real price of having a change not consistent with the rest of the system?
Will the quality be maintained? Speed perhaps will be sacrificed?
The whole idea of proposing Theory Building View of Programming is to better support changes — Naur claims.
Life, Death and Revival
Note: This paragraph relates to Program Life, Death and Revival chapter in the original paper.
The theory the developer has in the Theory Building View it is part of the program itself.
Thus, We can reason about the state of the program in relation to the theory still present in the current team, if any team is present at all.
The notion of Program Life, Death, and Revival
- life := the team possessing the theory is in control of the program.
- death := the team possessing the theory is dissolved.
- revival := the rebuild of the theory by a new team.
Interestingly enough Naur suggests that the revival state is a dangerous and expensive place to be, as the new team will struggle trying to change the program while building a theory. This will potentially generate poor results and a long time to implement the changes.
Walking Dead Programs:
Apparently, a program can be death and working perfectly! Only when a change will be required the state of death will be evident.
High churn rate teams:
Programs with teams having high churn rate risk to be in a revival state too, as the risk of losing the theory within the team increase.
Most likely, getting confidence with the current codebase and read the documentation won’t be enough to fully rebuild the program theory.
The most reliable way of building the theory is working in contact with programmers from the original team which have the theory under their supervision.
Opinions
In general, I agree with Naur’s Theory Building View.
The theory the developer has is a fundamental part to keep the program alive.
Naur is doing a step further suggesting that documentation and software methodologies won’t be effective against the decline of a program during the revival phase.
I agree on this, but I would like to extend it in a way (hopefully, without killing the core idea).
While in the paper seems to leave no further hope for the revival phase, I think that yes documentation and methodologies are not enough by themself.
I think that more information is required to increase the probability of a programmer rebuilding the theory.
Additional information that can facilitate the process:
READMEfilesCONTRIBUTINGfiles- Tasks used to during the build process with comments attached (Jira, track etc)
- A version control system (git, mercurial)
- Design
- Access to stakeholders
- Adopt standard and conventions
Isn’t that simply the documentation you may ask?
I think that README, CONTRIBUTING, tasks with all the comments attached, version control system and so on were not present in the way we got today. I think that the documentation Naur is referring to is more like a 100 pages manual.
What I want to point out, and possibly agree on, is that the amount of collateral information we produce today is at least one order of magnitude higher than the information that was produced in 1985.
This additional body of information may help in the process.
This won’t ensure it will be possible to re-create the 100% of the original theory but it will help, on reducing risks and helping maintain and retain the quality of the program.
Can you modify the software without the original developers then?
Yes, you can have changes without the original developers’ team.
Yes, these changes can work.
But keep in mind what Naur pointed out on the revival phase risks, and the consequences on plugging new developers in.
You do increase the risk to add inefficiency and sloppy the current system.
You do increase the risk to spend more time.
You do increase the risk to break other parts of the system.
You do increase the risk to introduce new bugs.
You do increase the risk to reintroduce old bugs.
And this is because a new developer if not properly instructed may not have yet a proper mental model of the system (the theory) and may miss some important functionality or design choice already in place.
If you introduce a new developer to a current solution you’ll have to expect a period for which he will have to build the theory (or part of) with the codebase before to be effective.
Conclusion
Peter Naur’s Programming as Theory Building is a dense paper full of insight on the real nature of programming. The paper is still remarkably actual and helps in the evaluation of strategic thinking for any software business.
The Theory To Be Built by the Programmer, Problems and Cost of Program Modification, Program Life, Death, and Revival are in my opinion the inner gems of this paper.
I couldn’t recommend it more.