Start here
Probably the best way to get acquainted with this work is to watch my presentation at DDD EU 2016. A reasonable follow-up (or "applied physics of software") is my talk “On Growth and Software” at nCrafts in Paris (May 2016). Slides for that talk are also available.
Recent papers
Cε-Stationary Design in the Physics of Software, March 2024 (draft).
Forces in the Physics of Software - the final word, January 2024 (draft).
Design, Conceptual Integrity, and Algorithmic Information Theory, April 2020 (draft).
Compressive Strength and Parameter Passing in the Physics of Software, April 2016 (draft).
Classic papers: a summary of "Notes on Software Design"
The first four chapters stemmed from a simple observation: that software tends to grow in a way that large modules get larger (many have observed this power law distribution). I postulated a form of gravity, which I thought was some sort of elementary force. Only later on I understood that it was a combined effect of temporal and spatial entanglement, but that portion never made it to the blog. Chapter 3 introduced the decision space. Chapter 4 explained that gravity was not "bad", it just was, and that we could learn to exploit gravity. This is in stark contrast with most methods, where things are always labelled as "good" or "bad", but more in accordance with natural sciences, where a neutral perspective is always assumed.
Notes on Software Design, Chapter 1: Partitioning
Notes on Software Design, Chapter 2: Mass and Gravity
Notes on Software Design, Chapter 3: Mass, Gravity and Inertia
Notes on Software Design, Chapter 4: Gravity and Architecture
Chapter 5 is more of an historical curiosity, as the concept explained here is "wrong", in the sense that I now have a much better explanation for the same phenomena (portions of source code or portions of data changing at the same time).
Notes on Software Design, Chapter 5: Multiplicity
Chapter 0 (yeah, it came after chapter 5) explained my goals for this work
Notes on Software Design, Chapter 0: What?
Chapter 6 introduced the idea of the artifact space and the run/time space, and how we tend to shift properties between the two.
Notes on Software Design, Chapter 6: Balancing two Worlds
I've always found visualization to be a great mind amplifier when dealing with complex problems. Still, the most common visualizations (UML diagrams) focus on the software shape, not on the problem shape. I introduced a notion of force field diagram in a previous post (A ForceField Diagram); Chapter 7 improved on that, although I'm still unsatisfied with the results and I've been playing later on with a different kind of diagram (entanglement diagram) which I've never published so far.
Notes on Software Design, Chapter 7: a better Forcefield Diagram
Again inspired by the simple fact that we tend to partition our artifacts in many different ways (blank lines, functions, classes, source files, components, etc), I introduced a notion of distance. According to the duality between the artifact and the run/time space, I explored the notion in both worlds.
Notes on Software Design, Chapter 8. A simple property: Distance (part 1)
Notes on Software Design, Chapter 9. A simple property: Distance (part 2)
The idea of observing software, instead of concocting ideas in a void, lead me to explore efficiency (and inefficiencies). Efficiency is a run/time thing, but again thanks to the duality between the artifact space and the run/time space, I've been able to extend a notion (friction) to both worlds.
Notes on Software Design, Chapter 10: Run-Time Friction
Notes on Software Design, Chapter 11: Friction in the Artifacts world
It took me a while to realize that what I misclassified in Chapter 5 was actually much deeper, and in the end would grow to be a fundamental part of the theory. Entanglement, a term that I borrowed from quantum physics, extends to the decision space, run/time space, and artifact space. The notion of entanglement is strictly related with the notion of change, and once again with the observation that in many cases, to maintain overall consistency, you need to apply changes in different places at the same time.
Notes on Software Design, Chapter 12: Entanglement
Notes on Software Design, Chapter 13: On Change
(chapter 14 is about something else)
Notes on Software Design, Chapter 15: Run-Time Entanglement
Design is an intentional act, and we should strive to avoid shapes that necessarily require continuous changes to our artifacts. Some language constructs, however, lead us exactly to that kind of shape. Here I'm introducing a theorem-like notion about instabilities in software, and a couple of chapters later, I'm back on that notion of instability and how the force field may look like an hourglass.
Notes on Software Design, Chapter 14: the Enumeration Law
Notes on Software Design, Chapter 16: Learning to see the Forcefield
Finally, I took some time to look at the classical approach to defining "a paradigm" in computing as a set of vague principles and/or values, and contrasting this with the idea of defining a structure by the way it reacts to forces. Here is a definition of object orientation not based on classes or objects at all, but on the way we expect it to react to entanglement with an open set of concepts:
Ask not what an object is, but...
(there is no "notes on software design" in the title, but it's really chapter 17, the premature end). This post provided some inspiration for my nCrafts talk “On Growth and Software”, where I finally moved outside the paradigm cage and defined the resulting structure as a Creational Structure instead.
Notes on Software Design, Chapter 1: Partitioning
Notes on Software Design, Chapter 2: Mass and Gravity
Notes on Software Design, Chapter 3: Mass, Gravity and Inertia
Notes on Software Design, Chapter 4: Gravity and Architecture
Chapter 5 is more of an historical curiosity, as the concept explained here is "wrong", in the sense that I now have a much better explanation for the same phenomena (portions of source code or portions of data changing at the same time).
Notes on Software Design, Chapter 5: Multiplicity
Chapter 0 (yeah, it came after chapter 5) explained my goals for this work
Notes on Software Design, Chapter 0: What?
Chapter 6 introduced the idea of the artifact space and the run/time space, and how we tend to shift properties between the two.
Notes on Software Design, Chapter 6: Balancing two Worlds
I've always found visualization to be a great mind amplifier when dealing with complex problems. Still, the most common visualizations (UML diagrams) focus on the software shape, not on the problem shape. I introduced a notion of force field diagram in a previous post (A ForceField Diagram); Chapter 7 improved on that, although I'm still unsatisfied with the results and I've been playing later on with a different kind of diagram (entanglement diagram) which I've never published so far.
Notes on Software Design, Chapter 7: a better Forcefield Diagram
Again inspired by the simple fact that we tend to partition our artifacts in many different ways (blank lines, functions, classes, source files, components, etc), I introduced a notion of distance. According to the duality between the artifact and the run/time space, I explored the notion in both worlds.
Notes on Software Design, Chapter 8. A simple property: Distance (part 1)
Notes on Software Design, Chapter 9. A simple property: Distance (part 2)
The idea of observing software, instead of concocting ideas in a void, lead me to explore efficiency (and inefficiencies). Efficiency is a run/time thing, but again thanks to the duality between the artifact space and the run/time space, I've been able to extend a notion (friction) to both worlds.
Notes on Software Design, Chapter 10: Run-Time Friction
Notes on Software Design, Chapter 11: Friction in the Artifacts world
It took me a while to realize that what I misclassified in Chapter 5 was actually much deeper, and in the end would grow to be a fundamental part of the theory. Entanglement, a term that I borrowed from quantum physics, extends to the decision space, run/time space, and artifact space. The notion of entanglement is strictly related with the notion of change, and once again with the observation that in many cases, to maintain overall consistency, you need to apply changes in different places at the same time.
Notes on Software Design, Chapter 12: Entanglement
Notes on Software Design, Chapter 13: On Change
(chapter 14 is about something else)
Notes on Software Design, Chapter 15: Run-Time Entanglement
Design is an intentional act, and we should strive to avoid shapes that necessarily require continuous changes to our artifacts. Some language constructs, however, lead us exactly to that kind of shape. Here I'm introducing a theorem-like notion about instabilities in software, and a couple of chapters later, I'm back on that notion of instability and how the force field may look like an hourglass.
Notes on Software Design, Chapter 14: the Enumeration Law
Notes on Software Design, Chapter 16: Learning to see the Forcefield
Finally, I took some time to look at the classical approach to defining "a paradigm" in computing as a set of vague principles and/or values, and contrasting this with the idea of defining a structure by the way it reacts to forces. Here is a definition of object orientation not based on classes or objects at all, but on the way we expect it to react to entanglement with an open set of concepts:
Ask not what an object is, but...
(there is no "notes on software design" in the title, but it's really chapter 17, the premature end). This post provided some inspiration for my nCrafts talk “On Growth and Software”, where I finally moved outside the paradigm cage and defined the resulting structure as a Creational Structure instead.
Related papers
Several posts on my blog were not "officially" part of the NOSD series, but contributed examples or explored implications of the theory.
A Tale of Two Methods, back from 2008, reflected on what I was trying to do with my early studies on the Physics of Software. I contrasted this with something I attempted about 10 years before. Later on, in On Kent Beck's Responsive Design, I reflected again on my perspective on software design, contrasting for instance my notion of distance with his first-person notion of steps.
Bad Luck, or "fighting the forcefield" mused on the notion of historical multiplicity from chapter 5. You can appreciate it more if you read it with the notion of entanglement in your mind.
Several papers explored the notion of design as a conscious decision process, and were therefore strictly related to the idea of a decision space:
Design Rationale
The Dependency Structure Matrix
A little more on DSM and Gravity
Delaying Decisions
A good theory allows us to draw interesting, new conclusions from known facts. In The CAP Theorem, the Memristor, and the Physics of Software I leveraged the run/time - artifact duality to extend the CAP theorem from the run/time space (where it was conceived) to the artifact world, explaining how a similar notion can be applied to components and distributed systems.
A new theory may also propose controversial solutions to old problems. Borrowing on some ideas hinted at in Chapter 16, I explained how the force field of a traditionally unstable system suggested a different, unconventional shape (and then encouraged people to stay away from it :-). Don’t do it!
A Tale of Two Methods, back from 2008, reflected on what I was trying to do with my early studies on the Physics of Software. I contrasted this with something I attempted about 10 years before. Later on, in On Kent Beck's Responsive Design, I reflected again on my perspective on software design, contrasting for instance my notion of distance with his first-person notion of steps.
Bad Luck, or "fighting the forcefield" mused on the notion of historical multiplicity from chapter 5. You can appreciate it more if you read it with the notion of entanglement in your mind.
Several papers explored the notion of design as a conscious decision process, and were therefore strictly related to the idea of a decision space:
Design Rationale
The Dependency Structure Matrix
A little more on DSM and Gravity
Delaying Decisions
A good theory allows us to draw interesting, new conclusions from known facts. In The CAP Theorem, the Memristor, and the Physics of Software I leveraged the run/time - artifact duality to extend the CAP theorem from the run/time space (where it was conceived) to the artifact world, explaining how a similar notion can be applied to components and distributed systems.
A new theory may also propose controversial solutions to old problems. Borrowing on some ideas hinted at in Chapter 16, I explained how the force field of a traditionally unstable system suggested a different, unconventional shape (and then encouraged people to stay away from it :-). Don’t do it!
More stuff
At some point, I created a presentation with links to various chapters. It's not dissimilar from this page in intent, and adds some perspective, but it became obsolete rather quickly.
