Overall, I would say my talk at DDDEU was well received, especially considering that it was the first time I tried to talk about the physics of software to a large audience, as opposed to a few like-minded colleagues.
It was not really easy to choose a reasonable subset to present. I felt I had to provide some background on why this theory is "needed", give at least a simple example of a force, and hint to the fact that there is much more than what I could show in 45m, so something about entanglement had to be there. In the end, I had to sacrifice many details and some amount of precision.
It was only reasonable that someone would call me out for my own lack of precision. While I intended to say something like "I'm using the term 'force' in a broad sense, like any kind of stimulus", in the end I didn't, and someone pointed out that my "forces" were not vectors etc. Which is right, and I don't think they'll ever be. I don't like the term stimulus and I'll keep saying force until I come up with a better term :-).
Another important notion I had no time to explain is that, just like in physics we have different types of friction (static and kinetic, but the whole field of tribology describes many different cases), so in software we have different types of resistance to motion. I described one of those cases (moving part of a function), where we move a portion of code with no identity . Different forces are at play when we move code with identity. Since I could not present the notion of identity in the artifact space, I've discussed only the simplest case.
I also left a few things unexplored, so here are a few pointers:
- I mentioned porting the CAP theorem from the run-time space, where it has been originally defined (the CAP theorem is about the behaviour of software) to the artifact space, that is, to make it about your code itself. I originally discussed that in The CAP Theorem, the Memristor, and the Physics of Software, back in 2011. There would be more to say about the techniques we can use to bring eventual consistency in the artifact space. The Postel Law, for instance, is also hinting in that direction. In fact, many software "principles" and "laws" are encoding heuristics in dealing with tacit forces that my work on the physics of software is trying to make (more) explicit.
- I also mentioned "code that is hard or inconvenient to move". An example of such code is in Notes on Software Design, Chapter 11: Friction in the Artifacts world, which was more about a notion of viscosity than friction, but the two notions are very close and at this stage I'm leaning on unifying them in a single concept.
The talk has been recorded and at some point will be available online. I'll keep you guys posted.
It was not really easy to choose a reasonable subset to present. I felt I had to provide some background on why this theory is "needed", give at least a simple example of a force, and hint to the fact that there is much more than what I could show in 45m, so something about entanglement had to be there. In the end, I had to sacrifice many details and some amount of precision.
It was only reasonable that someone would call me out for my own lack of precision. While I intended to say something like "I'm using the term 'force' in a broad sense, like any kind of stimulus", in the end I didn't, and someone pointed out that my "forces" were not vectors etc. Which is right, and I don't think they'll ever be. I don't like the term stimulus and I'll keep saying force until I come up with a better term :-).
Another important notion I had no time to explain is that, just like in physics we have different types of friction (static and kinetic, but the whole field of tribology describes many different cases), so in software we have different types of resistance to motion. I described one of those cases (moving part of a function), where we move a portion of code with no identity . Different forces are at play when we move code with identity. Since I could not present the notion of identity in the artifact space, I've discussed only the simplest case.
I also left a few things unexplored, so here are a few pointers:
- I mentioned porting the CAP theorem from the run-time space, where it has been originally defined (the CAP theorem is about the behaviour of software) to the artifact space, that is, to make it about your code itself. I originally discussed that in The CAP Theorem, the Memristor, and the Physics of Software, back in 2011. There would be more to say about the techniques we can use to bring eventual consistency in the artifact space. The Postel Law, for instance, is also hinting in that direction. In fact, many software "principles" and "laws" are encoding heuristics in dealing with tacit forces that my work on the physics of software is trying to make (more) explicit.
- I also mentioned "code that is hard or inconvenient to move". An example of such code is in Notes on Software Design, Chapter 11: Friction in the Artifacts world, which was more about a notion of viscosity than friction, but the two notions are very close and at this stage I'm leaning on unifying them in a single concept.
The talk has been recorded and at some point will be available online. I'll keep you guys posted.