3 ms·

So can you prove things with this "theory" are there theorems? What are the axioms? More like there is no theory. You just build it off of your gut feeling. Ma

So can you prove things with this "theory" are there theorems? What are the axioms? More like there is no theory. You just build it off of your gut feeling. Maybe you use big words like "dependency injection" or "domain knowledge" to make it feel like you have a theory but really you don't. When you have a theory, aspects of the design are calculated. Diagraming the architecture on a whiteboard is not theory. It's still gut feelings.

mmcdermott 3y ago
The underlying model can be thought of as the axioms. Going back to the Make example, it is trivial to think about axioms that describe the system's base abstraction ("Let T be a set representing targets...."). Generally speaking, the theory backing a system gets used to prove a few things. 1. Given a set of requirements we want to make sure that our model for the system can satisfy those requirements. If you cast your model as a series of logical formulae, then you can certainly decide to frame questions of requirement satisfaction as proofs or derivations. 2. Does a given codebase implement the theory/model we postulated? This is generally a code or design review conversation, but could certainly be the subject of formal verification. 3. Given a new requirement (formula) can we handle it with the existing system? The third option feeds into another of Naur's points throughout the paper, namely that there are limits to the evolution of a theory before it must be tossed out. If you are thinking of some systems that you have maintained that have ceased to make any kind of sense (a programmer described a system we were working on as a Winchester House for this very reason), then you have reached the point where the theory is lost which is equated with program death in the paper. I do find it curious that you refer to design patterns and diagramming. In my mind, design patterns are a way to communicate implementation details to others working on the codebase. Saying a service uses dependency injection is like saying a building uses an A-frame. Useful information to be sure, but no one thinks of "use an A-frame" as an architecture in itself. Similarly, diagramming is always a method of communicating. The map is not the territory. Some methodologies (I'm looking at you, UML craze) forgot that but it this paper far predates that particular period of folly.

mmcdermott 3y ago

The underlying model can be thought of as the axioms. Going back to the Make example, it is trivial to think about axioms that describe the system's base abstraction ("Let T be a set representing targets...."). Generally speaking, the theory backing a system gets used to prove a few things. 1. Given a set of requirements we want to make sure that our model for the system can satisfy those requirements. If you cast your model as a series of logical formulae, then you can certainly decide to frame questions of requirement satisfaction as proofs or derivations. 2. Does a given codebase implement the theory/model we postulated? This is generally a code or design review conversation, but could certainly be the subject of formal verification. 3. Given a new requirement (formula) can we handle it with the existing system? The third option feeds into another of Naur's points throughout the paper, namely that there are limits to the evolution of a theory before it must be tossed out. If you are thinking of some systems that you have maintained that have ceased to make any kind of sense (a programmer described a system we were working on as a Winchester House for this very reason), then you have reached the point where the theory is lost which is equated with program death in the paper. I do find it curious that you refer to design patterns and diagramming. In my mind, design patterns are a way to communicate implementation details to others working on the codebase. Saying a service uses dependency injection is like saying a building uses an A-frame. Useful information to be sure, but no one thinks of "use an A-frame" as an architecture in itself. Similarly, diagramming is always a method of communicating. The map is not the territory. Some methodologies (I'm looking at you, UML craze) forgot that but it this paper far predates that particular period of folly.