Disclaimer: This post comes in an unusual form. Carlo had the kindness to review it, and his feedback was so valuable that I actually decided to add it in the post.
To be clear, I know I’m still an alchemist. But I try to show which kind of insight “physics of software” has bring to me. Very far from being perfect, even probably far from being pertinent, but still a little bit much better to me than my previous understanding of software design.
My hope is to make physics of software (like DDD) more accessible to people less informed like me.
Carlo‘s comments will appear in blue.
I recently tried to explain why Time can be considered as a dimension, like Decision, Artifact and Runtime. But this dimension has some particularity : it impacts the 3 other dimensions. It’s hard to find principles or practices being part of this dimension only.
Could it be better then to consider Time as a force instead of as a property?
—–
I tend to see things quite differently here:
- Decisions / artifacts / runtime are spaces, not dimensions. Each of those is a multi-dimensional space.
- Just like in newtonian physics you have a 3D space and then you have time, and time is the axis along which any change happens (movement happens in time, waves require time, etc) so in the (newtonian) physics of software you need time to complement each space. As you already know I tend to see two different kind of time in the artifact – runtime space.
- While I understand the wish to go Einstein and model software after a single “spacetime” notion, at this stage I don’t see the value of doing so. It doesn’t mean it has no value – just that at the scale I’m working right now I don’t see the value and I lose useful concepts. Just like most engineering is done at the newtonian level, and only when needed we move to quantum mechanics or to relativity, so I suppose it will be appropriate for software. At this stage we don’t even have newtonian physics so it’s hard to say 🙂
- I really have an hard time considering time a force, because I still need time to understand the effect of any force. You apply a force and something happens -> in time.
We are software Alchemist
Carlo explains how close we are to alchemy when talking about software design.
Instead of a scientific approach, we tend to have philosophical debates on what could be the best options to design software, using terms we barely understand.
We talk about “code smells”, describing how we feel about code. We are looking for the “philosopher’s stone”. How do we define “too much coupling”, in a non ambiguous way ? We can’t, still we argue for hours on this topic.
Force in software
In science, to define a property (let’s say thermal conductivity property) we need to understand the forces altering the object (let’s say temperature gradient). Then we can precisely define, in a given context (a piece of wood under standard pressure) what is its thermal conductivity property.
We do not have this precision in software yet, but we could look for forces and observe how our design reacts under given conditions.
Time as a force
Like gravity in physics, Time in software impacts all the dimensions.
Time applying to the Decision dimension is the acceptance that we can’t foresee the future. The best known strategy is : adapt to survive. Practices around lean management emerged to cope with this fact. Flat hierarchies are pushed because it allows a company to adapt faster.
Time reveals the adaptability of our business model.
In the Artifact dimension, applying Time shows if your code is supple enough to cope with new requirements. It is the difference between make it work, and make it clean. It could work quickly, but it will take more thinking to make it clean, ready to evolve, and protected against regression. This is where we’ll need low coupling and automatic testing.
Time reveals the adaptability of our code.
To have a stable Runtime over Time, we need to be scalable, secure and resilient to hardware failure. It is hard to achieve, because it requires the software to be able to react depending on how it is used. It is a complex dimension, due to interaction between software and hardware.
Time reveals the adaptability of our runtime.
—–
This entire section is interesting, but it’s still coming from the “alchemic” perspective. It is all very reasonable, but it written in the style of all the (alchemic :-)) stuff to which we are constantly exposed. “Time reveals the adaptability of our code”. That’s true, and if you write it in this way, it seems like time is taking an active role in that, like it’s actually going in and do stuff. But it’s not. In a scientific perspective, you won’t be able to formalize, prove, replicate the “agency” of time. If you try to be more precise, to decompose things, you’ll see that changes happen in the decision space (over conventional time), and that those changes are the forces impacting your artifacts. Conventional time is “just” the dimension that allows changes to happen in the decision space. That process can be semi-ordered or largely chaotic. But the agent is not time. The agent is change.
The adaptability property
To start from a force and try to find properties in software seems already a bit clearer to me. Not perfect but at least we can better describe what we are talking about. Adaptability in reaction to Time makes sense in the different dimensions of software. Maybe we could find some way to measure it ?
—–
Ok, this is close to the perspective of the physics of software, it’s just that I would say “adaptability in reaction to change” (not “in reaction to time”) and then investigate the nature of change (which is something I’m actually working on). See, once you begin with change, you have something you can further decompose. Is that change a creation of something new? Is that something similar to something else we had? It’s ordered / planned change? Is it a modification of something we had? Which kind of modification? In physics we have many properties that in software are collapsed under “adaptability”. Plasticity, extensibility, malleability, flexibility, compressibility, elasticity, etc. A real physics requires this level of decomposition. But (and this is the real point here) if you only have “time” as a force, you can’t decompose further. If your force is change, then yes, you can. A first step was in my ncrafts talk, that is more about “planned growth”.
The predictability property
Thinking about it, I realize it was my problem when speaking about Technical Debt. What’s technical debt ? How can we define « too much » technical debt ? It explains why I need to speak about predictability instead. Again it is not perfect, but it is less ambiguous. And Time is definitely a force helping to reveal the predictability property in the different dimensions as well.
—
Ok, I would say something like above. Predictability is interesting – it’s about having a reasonable model for changes, and it’s what I mean when I talk about planned vs organic change (terms that I’ve taken from urbanism). I still see time as the dimension that allows changes to happen one at a time 🙂 and not as the force.
The philosopher’s stone
We have been looking for the philosopher’s stone for too long in our industry. It would be healthier to have a more scientific approach.
We are still very far from it, but looking for forces and properties may be a good start to improve the state of the art of software development.
Thanks a lot to Brian Gibson and Carlo Pescio for the review.
Please read Carlo’s post for more explanation about Time in the physics of software.