Building models and solutions in software is not just about programming. We will review Peter Naur's classic paper. This classic article from 1985 anticipated many of the concepts that are in common use in the industry today. There are other interesting inspirational ideas from the paper that we have not yet taken advantage of. Historic context Peter Naur's brings us concepts that still go unnoticed today. paper from 1985 Written documentation was the model to follow. The reigned supreme and was the industry standard. Peter Naur challenges us to reflect on our profession and brings us concepts that are still very relevant 25 years later. Cascading Lifecycle Peter Naur was a Danish scientist, winner of a (equivalent to the Nobel Prize in computing). He took part in the development of and helped create the syntax model that all programming languages ​​use to define their grammar. Turing Award Algol 60 BNF By 1985, Naur had discovered the difficulty in the education of computer professionals and its radical difference from other engineering disciplines. His collaborative and human conception always contrasted with the Taylorist concepts of software development that see activities as watertight compartments and human beings as interchangeable pieces. His epistemological approach, based on incremental iterative learning, contrasts with mathematics represented by the formal ideas of . Dijkstra Theory building The paper presents novel ideas for the time, then taken up by the placing humanistic values ​​of knowledge acquisition over the Taylorist vision of software building. agile manifesto The theory is built by observing reality as in scientific procedure. The individuals jointly assemble the emergent knowledge of said observations. In this knowledge the is greater than as Aristotle correctly predicted. whole the sum of the parts The programming phase corresponds to the implementation stage of said theory in a machine. This idea is partially contradicted by techniques such as where knowledge training is encouraged while the solution is implemented. TDD What is (wrong with) software? Documentation of findings According to Naur, software developed and the accompanying documentation are not enough to express the design ideas developed in theory. Ideas exist only among the individuals who formulated them. Therefore, the loss of any of its members, the collectively generated knowledge. fragments Photo by Matt Artz on Unsplash Agile ahead of time The is based on four pillars: agile manifesto 1 over processes and tools Individuals and interactions This corresponds to Naur's ideas about the importance of people who are shaping knowledge. 2 over comprehensive documentation Working software As we saw earlier, the documentation is irrelevant and is not a good starting point for further software development. 3 over contract negotiation Customer collaboration Communication to build the theory between the people developing the software, and the domain experts, is essential for that theory to correspond to a useful solution. As a corollary, only formal communication between the parties is counterproductive. 4 over following a plan Responding to change The theory developed is a process that does not have an initial plan or an end goal. It is an incremental spiral where theory adjusts to needs as it learns from the real world. Axioms don't matter Peter Naur's theory is not based on formal axioms with postulates, derivation of theorems, or corollaries. Instead, look for a declarative model that explains the business we are simulating. This way of doing science is based on which, in turn, is based on the constructivist ideas about the language of . Ryle Wittgenstein Building software is acquiring knowledge. Trying to define the behavior of a class without having previously built any instance is a mistake. What Exactly Is A Name: Rehab [Part II] To build theory in an exploratory way, ​​are much more useful tools than . prototyping languages classification languages Naur believes that there is no single scientific method but that there is a multiplicity of them. In accordance with ideas. Feyerabend's This theory is understood as the knowledge a person must have in order not only to do things intelligently and
 well according to certain criteria, but also to be able to explain, answer questions, argue or justify the activity of concern. Human beings are the center The theorybuilt cannot be expressed in the developed program. It can only be enunciated by the human beings who participated in its building. Software is the product of these ideas. Before a a similar theory can be reconstructed from the artifacts. This theory will be with respect to that elaborated by the original authors. change of people incomplete and different The asset of a software company is not the lines of source code with intellectual property that only reflect explicit knowledge. The people who develop that theory and build that software possess irreplaceable, and therefore valuable, implicit knowledge. The theory builders are based on a certain paradigm, as established by . The paper mentions that, to know Newton's theory, it is not enough to read only the physical formulas. Kuhn The person having the theory must have an understanding of the manner in which the central laws apply to certain aspects of reality, so as to be able to recognize and apply the theory to other similar aspects. A person having Newton’s theory of mechanics must thus understand how it applies to the motions of pendulums and the planets, and must be able to recognize similar phenomena in the world, so as to be able to employ the mathematically expressed rules of the theory properly. If the model does not exist, the results will never be as expected Naur begins the article by taking certain observations of what really happens with programs and the teams of programmers who deal with them, particularly in situations that arise from unexpected and erroneous executions or reactions of the software. The difficulty of accommodating such observations in a production view of programming suggests that this view is misleading. The theory building view is presented as an alternative. Building adequate and self-defense models is not easy. It requires a long process of mastery learning. Its fruits allow us to mitigate risks and to be able to maintain the existing software. There are no silver bullets Naur rejects the idea of ​​a single method to develop software. A development methodology, such as the one already mentioned , must be complemented with other practices. TDD The absence of the much desired is a sad reality, even these days. silver bullet Language is accidental According to Naur, the notation used to express this theory is accidental. Today we know that language is an inseparable part of what it can express. It is not the same to write an algorithm in a language than in a one. declarative low-level Nor will we be able to express good business models in non-declarative languages ​​like or . C GoLang In the same way that we should not describe chemical or physical equations in natural language, we should not express our theory in languages. low-level The software should not be seen as the text that can be uploaded to a repository but as the . theory that supports it Photo by Roman Mager on Unsplash Bad decisions Throughout the theory building process, those involved make decisions so that the model corresponds to the . These decisions are not explicitly documented. bijection to the real world Observing the result without knowing why a design decision was made is another limitation that a theory can explain but the built software cannot. In legacy systems it is common to see individuals act out of habit without wondering what reasons lead them to make decisions. Where is the model? According to Naur, the model should remain solely as theory among the participants. However, if we stay true to bijection and create a model with a the model will be only as good as the theory developed in it. MAPPER and the others are cornering programmers who write code without understanding the underlying theory. We still have time to avoid it. GPT3 transformers Conclusions Building software is a human activity. Theory building is a mental activity that requires a process of learning and discussion until reaching a consensus. Part of the objective of this series of articles is to generate spaces for debate and discussion on software design. We look forward to comments and suggestions on this article. You can hit me up on . twitter

Twitter

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

Programming as Theory Building

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

From Helpful to Harmful: How AI Recommendations Destroyed My OS

Why Great Leaders Thrive in Contradiction, Not Certainty

Three features I would add If I was a Product Manager at WhatsApp

Blending Worlds: How to Integrate External IPs Without Losing Your Game’s DNA

When Documentation Lies: Detecting Drift Between Code and Reality

You Don't Have a Prompt Problem. You Have a Context Problem.

From Helpful to Harmful: How AI Recommendations Destroyed My OS

Why Great Leaders Thrive in Contradiction, Not Certainty

Three features I would add If I was a Product Manager at WhatsApp

Blending Worlds: How to Integrate External IPs Without Losing Your Game’s DNA

When Documentation Lies: Detecting Drift Between Code and Reality

You Don't Have a Prompt Problem. You Have a Context Problem.

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps