Programming as Theory Building

• Peter Naur's 1985 essay provides an exceptionally accurate account of the actual process of designing and coding software.
• Programming is properly understood as an activity where programmers form a theory or insight about the matters at hand, rather than merely producing program texts.
• The quality of a programmer's work depends on the match between their theory of the problem and their theory of the solution.
• When passing work to later programmers, the goal is to transfer the theories driving the design rather than just the design itself.
• Because the underlying theory relies on tacit knowledge, conventional documentation alone is often insufficient for transferring complete understanding.

This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.

• Program text and documentation often serve as secondary products compared to the programmer's immediate possession of the theory.
• Group B attempted to build an extended compiler using Group A's existing compiler and full documentation as a starting point.
• Despite having complete documentation, Group B repeatedly proposed architectural patches that destroyed the simplicity of the original structure.
• Personal advice from Group A was crucial because they instantly spotted how to use existing facilities rather than resorting to destructive patches.
• Over a span of ten years without original guidance, the compiler's powerful structure was rendered entirely ineffective by amorphous modifications.
• Ultimately, program text and documentation alone consistently prove insufficient as carriers of vital design ideas.

In several major cases it turned out that the solutions suggested by group B were found by group A to make no use of the facilities that were not only inherent in the structure of the existing compiler but were discussed at length in its documentation, and to be based instead on additions to that structure in the form of patches that effectively destroyed its power and simplicity.

• Large real-time systems rely heavily on continuous programmer involvement for fault diagnosis and maintenance.
• Programmers managing these systems depend on personal knowledge and annotated text rather than formal documentation.
• The maintenance of complex software is essentially dependent on the tacit knowledge of dedicated programmer groups.
• A programmer's knowledge can be conceptualized as a theory in the philosophical sense described by Ryle.
• Intellectual activity and intelligent performance involve the ability to do things well and apply criteria without infinite rule regression.

When diagnosing a fault these programmers rely almost exclusively on their ready knowledge of the system and the annotated program text, and are unable to conceive of any kind of additional documentation that would be useful to them.

• Intellectual activity goes beyond simple intelligence by involving the creation and possession of a theory for explanation and argumentation.
• The concept of theory applies not just to specialized academic fields, but also to everyday activities like planning or navigation.
• Having a theory requires understanding how central laws apply to reality and recognizing similar phenomena in the world.
• The knowledge held within a theory cannot be fully expressed in terms of rules because real-world similarities resist strict criteria.
• Programmers must build a theory of how computer programs handle real-world affairs, which holds primacy over program texts and documentation.
• The programmer's underlying knowledge inherently transcends what can ever be captured in documented products.

The dependence of a theory on a grasp of certain kinds of similarity between situations and events of the real world gives the reason why the knowledge held by someone who has the theory could not, in principle, be expressed in terms of rules.

• A programmer possessing the theory of the program can explain how the solution relates to real-world affairs.
• The programmer must be able to map every part of the program text to corresponding aspects or activities of the world.
• Justification for why each part of the program exists relies fundamentally on the programmer's direct, intuitive knowledge.
• Modifying a program to support new demands requires a perception of similarity between world aspects known only to the programmer.
• Software will inevitably be modified once operational as use inspires ideas for further useful services.
• Program modifications are driven by the hope of achieving cost savings compared to writing an entirely new program.

The final basis of the justification is and must always remain the programmer's direct, intuitive knowledge or estimate.

• Modifying complicated man-made constructions is usually more expensive than rebuilding from scratch, contradicting the assumption of cheap program modifications.
• While text editors make program modification seem easy, assuming text manipulation is the dominating cost relies on a flawed view of programming as mere text production.
• Building flexibility into a program requires substantial design, implementation, and testing costs whose usefulness depends entirely on uncertain future events.
• Program modifications require confronting an existing solution with new demands to determine similarities, which relies on human insight rather than rigid rules.
• Problems in program modification stem directly from the mistaken assumption that programming consists of text production rather than ongoing theory building.

This need for a determination of similarity brings out the merit of the Theory Building View.

• Modifications to a program can achieve the same external behavior while having vastly different relationships to the program's underlying theory.
• Changes that are inconsistent with the program theory act as unintegrated patches and degrade the long-term viability of the software.
• Qualities like simplicity and good structure only make sense in relation to the unexpressed theory held in the programmer's understanding.
• A program effectively dies when its original team of programmers dissolves, even if the software continues to execute on a computer.
• Reviving a dead program requires a new team to rebuild its theory through direct collaboration with existing theory-holders rather than just reading documentation.

The death of a program happens when the programmer team possessing its theory is dissolved.

• Programming involves students engaging in relevant supervised activities, including discussing how programs relate to the real world.
• The Theory Building View dictates that program revival solely from documentation is strictly impossible.
• Attempting to revive a dead program is costly and likely to result in discrepancies, making starting fresh preferable.
• Similar challenges emerge in continuously evolving programmer teams due to varying individual competencies and member replacements.
• Programming methods are defined as sets of work rules, but the Theory Building View argues that a programmer's theory has no inherent ordering.
• Consequently, under the Theory Building View, there can be no single correct method for the primary activity of programming.

The new programmer is likely to feel torn between loyalty to the existing program text, with whatever obscurities and weaknesses it may contain, and the new theory that he or she has to build up.

• The Theory Building View challenges established opinions regarding the necessity and existence of rigid scientific and software development methods.
• Philosophical analyses by Feyerabend and Medawar suggest that the popular notion of a strict scientific method is a mistaken concept.
• Problem-solving guides, such as those by Polya, offer helpful mental suggestions rather than a mandatory sequential procedure.
• Published reports claiming the success of specific programming methods lack rigorous controlled experiments and systematic empirical backing.
• Extensive studies, including work by C. Floyd, demonstrate that the idea of methods as mechanical rules for good solutions is an illusion.
• While specific techniques aid programmer education and theory building, the choice of which to use must remain entirely up to the programmer.

What remains is the effect of methods in the education of programmers.

• Traditional software studies often ignore the personal contributions and background of individual programmers.
• Prevailing industry views mistakenly treat programming as routine industrial production and programmers as easily replaceable parts.
• The Theory Building View posits that a programmer's primary output is their internal theory of the system.
• Programmers should be recognized as responsible professionals rather than low-responsibility factory workers.
• Education must shift focus from mere formal notations toward fostering active theory formation and intellectual proficiency.

More generally, much current discussion of programming seems to assume that programming is similar to industrial production, the programmer being regarded as a component of that production, a component that has to be controlled by rules of procedure and which can be replaced easily.

• Programming is primarily about building a theory of how the program supports the problem domain rather than just writing code.
• Program modifications require continuous support from programmers who possess this underlying theory.
• Traditional programming methods based on rigid rules of procedure are considered invalid and should be rejected.
• Programmers must be treated as responsible, permanent developers and managers rather than interchangeable parts.
• Education needs to prioritize theory building alongside data processing knowledge and notations.

That is an extraordinary power for just the two words, 'assembly line.'

• Parallel coding without a shared theory leads to an increasingly complicated and incoherent system design.
• A common metaphor enables team members to predict each other's work and integrate new code seamlessly.
• The primary goal of documentation is to help future programmers build an adequate mental theory of the program.
• Effective documentation focuses on metaphors, component purposes, and major interactions rather than exhaustive details.
• Clean source code and consistent naming conventions fundamentally aid readers in constructing a coherent system theory.

The documentation is almost certainly behind the current state of the program, but people are good at looking around.

This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.

In several major cases it turned out that the solutions suggested by group B were found by group A to make no use of the facilities that were not only inherent in the structure of the existing compiler but were discussed at length in its documentation, and to be based instead on additions to that structure in the form of patches that effectively destroyed its power and simplicity.

• A program effectively dies when its original team of programmers dissolves, even if the software continues to execute on a computer.

The death of a program happens when the programmer team possessing its theory is dissolved.