When I finished reading Peter Naur’s Programming as Theory Building my first thought was “How come nobody ever told me to read this?” I ended up reading it multiple times, as I attempted to collect my thoughts on why it makes so much sense.

Have you ever had a situation where you’re trying to explain something or say something, and you’re looking for a suitable word or term, but no matter how much you look for it, you can’t find it? I think Naur’s “theory” is that term when it comes to writing good code and creating maintainable software. I’ve had many ideas and thoughts on those topics, but they were all disparate concepts, which even when grouped together didn’t really answer the question “why is writing good software hard?” Viewing programming as “theory building”, as Naur puts it, is the missing piece that pulls all of it together and answers the question.

In summary, Programming as Theory Building suggests that the program code, documentation and other products are secondary to what programming really is about: Building an understanding, or a mental model, of the program, its requirements, and how they relate to everything around it. That is, your primary goal as a programmer is to learn, understand, retain, improve and share this “theory” of the program.

If you think of things like “good code” or “maintainable code”, what is it that comes to mind? It’s probably things that make code easier to understand, like following good conventions, writing “clean” code, having a good architecture, and so on. You might also think of documentation and diagrams. Perhaps automated tests.

If you think about it, the goal with everything that relates to writing maintainable code is actually about communicating the design intention of the code. You write clean code because it’s easy to understand what it does, you architect code so it’s easy to understand its structure and purpose of the structure, you add documentation to help explain what the code does, and draw diagrams for similar purposes as well. But at least in my experience, developers treat the different aspects of this as separate activities - eg. writing tests is its own activity with its own goals, writing documentation is its own activity, and so forth.

If you look at programming as theory building in the way Naur suggests, you can see these activities as part of a larger whole: Communicating the theory of the program. When seen as part of a larger whole, you can start using the separate activities to achieve the shared goal better. And communicating the theory of the program is important: If you try to modify a program without having an understanding of the theory, you won’t be able to do it in a way that isn’t hacky. Similarly, if you need to evaluate the feasibility of some change to the code, such as a new feature, you cannot do this unless you have an understanding of the theory.

In this sense, programming is theory building.

If you think of it in this way, suddenly many more things connect together. For example, what do design patterns and Domain-Driven Design have in common? They help you communicate ideas and mental models used in your code - that is, they help communicate the theory of the program. Similarly, others have suggested concepts like Intellectual Control - having a mental model of the program, allowing you to confirm it works correctly, and reason about changes to it and so forth - which could also be seen as a form of “theory building”.

Hopefully I’ve managed to convey at least some of the value of reading Peter Naur’s essay. There’s more to it, so I highly recommend reading the original “Programming as Theory Building” text. It isn’t too long, and you can find it pretty easily on Google - I would link it, but it’s a bit of a gray area copyright-wise, and I’d have to deep link it from someone’s website. If you have read it, I’d love to hear your thoughts on it.