Recently Emilien Pecoul has posted an interesting commentary on the physics of software (Coding in N dimensions). He makes two major points:
- the need to introduce time along with the 3 spaces in the physics of software
- the ability of a software professional to move through the 3 spaces (run-time / artifact / decision)
I added a comment on the latter on his blog (so if you’re interested just go there and read his post too :-) but I thought I could add something about Time here, because I’d like to keep most of the “core stuff” in one place.
Emilien is right that I didn’t talk about time in my DDDEU presentation. I only had 45 min, and there was no time for Time. However, time plays an important role in the physics of software; also, we’ll see that it extends beyond our conventional notion of time.
Let’s start with the run-time space, because things are always easier there. We already know that we often deal with two notions of time when we think about the run-time space:
- conventional time, or “elapsed time”. When we think about a timeout, especially if it concerns communicating with something outside our system, we think about conventional time.
- CPU / process time. When we want to measure the “efficiency” of CPU-bound code, elapsed time is not a good measure. If our process was not scheduled for some (elapsed-time) interval, CPU time actually *didn’t change* in our reference frame. I tend to say “Machine Time” instead of “CPU time” to avoid dragging in terminology like CPU, scheduler and so on.
Machine Time is quantized / discrete, as it normally moves in clock ticks. Its relationship with elapsed time depends primarily on scheduling, and it’s non-deterministic in any architecture with interrupts.
Interestingly, there are / have been clockless CPUs, although they never really got traction. They fall in the more general category of asynchronous, self-timed circuit (see the wikipedia page for an introduction). Now, with an asynchronous CPU, Machine Time “flows” depending on availability of data / need to compute, and that’s logically close to a data-flow model, but (this would be a long story) you can also see it as unfolding according to run-time entanglement. Information enters the run-time space, and it’s propagated and transformed along the path set by run-time entanglement.
Now let’s move to the artifact space. Here too we can consider two notions of time. One is again the conventional time. It’s what allows us to say that we made a change or created an artifact at a specific moment in (conventional) time. It’s useful in some scenarios, but it’s not the most relevant notion of time we need to consider when we think about the artifact space.
I’ll take a short diversion to explain why. There is a common phenomenon known as “software aging” or even “software rot” (see for instance wikipedia again). Now, as usual in software, many different notions are conflated into that single, vague concept. So some people consider degradation through cumulative insertion of defects a component of software rot; others consider the misalignment with current requirements a component, and so on. If we stay at this level of vagueness, the concept is bound to remain an interesting metaphor and nothing more.
If we decompose it, we may notice a component that is particularly relevant here. Say that at some time T1 you have a set of (technical and business) decisions {D1,…,Dn} and that your set of artifacts {A1,…,Ak} is in perfect alignment with those decisions (yes, that’s not possible in practice, but it’s ok for the reasoning). Say that {D1,…,Dn} do not change for a long (conventional) time. Your software won’t experience any aging / decay / rot. It’s perfectly fine and functional. It’s only when one of those decisions changes that the knowledge encoded inside your artifacts is no longer aligned with the decision space. That’s a “clock tick” in the artifact space, that is really making it age / rot / decay. Once again, the tick is carried over through a form of entanglement, this time by the decision -> artifact (cross-space) entanglement.
I tend to call this dimension the “Decision Time”, even though it’s advancing time in the reference frame of the Artifact space. As usual, I’m open to better names. BTW: it easily follows from the above that every model of decay based on conventional time makes little sense. Your FFT code ain’t going to decay any time soon (with relevant decisions here being only the language or HW that may have influenced the code; the algorithm itself is quite stable). Of course, the decision of using an FFT is still open to change.
Finally we have time in the decision space, and we normally consider conventional time here, because we are outside the realm of encoded information and in close contact with humans, society, regulations, etc.
There are many other places where time plays a role in the physics of software. For instance, my talk “On Growth and Software” was about software growing… over time, of course. So time is a pervasive notion in the physics of software, and this short post can only be considered as a proxy for a much larger chapter of an unwritten book.
Feedback is welcome as usual; go ahead and open a Time topic in the forum under “discussion on concepts” if you can’t find one yet.
- the need to introduce time along with the 3 spaces in the physics of software
- the ability of a software professional to move through the 3 spaces (run-time / artifact / decision)
I added a comment on the latter on his blog (so if you’re interested just go there and read his post too :-) but I thought I could add something about Time here, because I’d like to keep most of the “core stuff” in one place.
Emilien is right that I didn’t talk about time in my DDDEU presentation. I only had 45 min, and there was no time for Time. However, time plays an important role in the physics of software; also, we’ll see that it extends beyond our conventional notion of time.
Let’s start with the run-time space, because things are always easier there. We already know that we often deal with two notions of time when we think about the run-time space:
- conventional time, or “elapsed time”. When we think about a timeout, especially if it concerns communicating with something outside our system, we think about conventional time.
- CPU / process time. When we want to measure the “efficiency” of CPU-bound code, elapsed time is not a good measure. If our process was not scheduled for some (elapsed-time) interval, CPU time actually *didn’t change* in our reference frame. I tend to say “Machine Time” instead of “CPU time” to avoid dragging in terminology like CPU, scheduler and so on.
Machine Time is quantized / discrete, as it normally moves in clock ticks. Its relationship with elapsed time depends primarily on scheduling, and it’s non-deterministic in any architecture with interrupts.
Interestingly, there are / have been clockless CPUs, although they never really got traction. They fall in the more general category of asynchronous, self-timed circuit (see the wikipedia page for an introduction). Now, with an asynchronous CPU, Machine Time “flows” depending on availability of data / need to compute, and that’s logically close to a data-flow model, but (this would be a long story) you can also see it as unfolding according to run-time entanglement. Information enters the run-time space, and it’s propagated and transformed along the path set by run-time entanglement.
Now let’s move to the artifact space. Here too we can consider two notions of time. One is again the conventional time. It’s what allows us to say that we made a change or created an artifact at a specific moment in (conventional) time. It’s useful in some scenarios, but it’s not the most relevant notion of time we need to consider when we think about the artifact space.
I’ll take a short diversion to explain why. There is a common phenomenon known as “software aging” or even “software rot” (see for instance wikipedia again). Now, as usual in software, many different notions are conflated into that single, vague concept. So some people consider degradation through cumulative insertion of defects a component of software rot; others consider the misalignment with current requirements a component, and so on. If we stay at this level of vagueness, the concept is bound to remain an interesting metaphor and nothing more.
If we decompose it, we may notice a component that is particularly relevant here. Say that at some time T1 you have a set of (technical and business) decisions {D1,…,Dn} and that your set of artifacts {A1,…,Ak} is in perfect alignment with those decisions (yes, that’s not possible in practice, but it’s ok for the reasoning). Say that {D1,…,Dn} do not change for a long (conventional) time. Your software won’t experience any aging / decay / rot. It’s perfectly fine and functional. It’s only when one of those decisions changes that the knowledge encoded inside your artifacts is no longer aligned with the decision space. That’s a “clock tick” in the artifact space, that is really making it age / rot / decay. Once again, the tick is carried over through a form of entanglement, this time by the decision -> artifact (cross-space) entanglement.
I tend to call this dimension the “Decision Time”, even though it’s advancing time in the reference frame of the Artifact space. As usual, I’m open to better names. BTW: it easily follows from the above that every model of decay based on conventional time makes little sense. Your FFT code ain’t going to decay any time soon (with relevant decisions here being only the language or HW that may have influenced the code; the algorithm itself is quite stable). Of course, the decision of using an FFT is still open to change.
Finally we have time in the decision space, and we normally consider conventional time here, because we are outside the realm of encoded information and in close contact with humans, society, regulations, etc.
There are many other places where time plays a role in the physics of software. For instance, my talk “On Growth and Software” was about software growing… over time, of course. So time is a pervasive notion in the physics of software, and this short post can only be considered as a proxy for a much larger chapter of an unwritten book.
Feedback is welcome as usual; go ahead and open a Time topic in the forum under “discussion on concepts” if you can’t find one yet.
RSS Feed
