Time-Aware design

I already advocated how an Event Driven Architecture allows our code to be more aligned with our business. Mike has the same conclusion, focusing on Practical Event Sourcing.
But why such a system is by design more aligned with the business?onceaponatimeBecause it tells a story 

Good code must tell a story.
It must tell a story to the business experts to help them take their next decision. It must tell a story to the developers to help them grab the flow of the system. It must tell a story to the users, to help them use the software.
A story is nothing but a succession of important Events.


Because it stores root causes instead of consequences

Storing the root causes of a decision is more interesting than storing its consequences. It’s always possible to derive the current state of our system by re applying the root cause and subsequent Events.
But if only the current state is known, it is harder to find what happened in the past.


Because it is a « free » logging system

Why do we use logging at Runtime? Because we try to guess the story.
If by design we track every important Event, the logging system is « free », in the sense that no more infrastructure is required to support logging.
Events can be used retroactively by the business to look for interesting correlation in the data.


Event Driven limits

There is no free lunch though.
Event Driven systems have very low coupling, which improves maintenance, but hurts navigability. When interactions between classes are done using Events, navigation is harder to follow the flow of a use case.
It will be hard to build a team of developers used to this design, as it is not mainstream. The team will need training, to perform the required mindset shift.
Also it is often implemented with no-SQL storage, a less mature technology than SQL storage.


Event Driven Architecture introduces Time in design

We know we lack the representation of time in software despite of its fundamental impact. Even if it has limits, Event Driven Architecture is a way to fill this lack by introducing time at the heart of the software.
It facilitates the alignment of our code with our business, and with the runtime.
It allows less friction between the different dimensions.
It is a Time-Aware design.



Thanks Gautier for your suggestion to replace TimeFull by Time-Aware.



The force of Time in software

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.badge-alchemistI 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.isaac%20newton

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.star-wars-and-the-forceTime 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”.adaptability-4-638The 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.predictabilityThe 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.

Coding in N dimensions

I discovered this year Carlo Pescio‘s work on the physics of software. He has a scientific approach of software design. This video from DDD Europe is a good way to discover his work.

Combined with the amazing talk from James Coplien, it gives me a lot of things to process since january to improve my understanding of software design.


Designing in 3 dimensions

Carlo speaks of the 3 dimensions in software: Runtime, Artifact (Codebase) and Decision (Business).

He explains there are interesting symmetries between these 3 dimensions. For example, a change in decision requires a change in codebase, to produce a change in behaviour at runtime.
We understand the consequences of developing hard to change code: we make the business hard to evolve. Immutable business decisions are utopian, so code must be able to adapt.

It resonates with James’s talk about symmetries in design.


A fourth dimension?

We often forget to represent time when speaking about design, as James explains.

It is a shame because use cases (what matters to the business) involves Time. We should add it to the three dimensions already exposed.

There are symmetries between Codebase and Time for example. Designing software for a one shot use is really different from designing software expected to run for the next decade.


Developer maturity

These dimensions could be useful to estimate our maturity as developer. It is relative to the number of dimensions we take into account when designing software.

Here are a few typical focuses related to each dimension:

Runtime :
We focus on technologies when thinking in the runtime dimension. We want to make it work, as quickly as possible. We are concerned with performance and optimization to have fast execution.

Artifact :
When focusing on code, we are interested in the organization of our code. We may apply GOF patterns, solid principles and other technical practices to keep our code easy to maintain.

Decision :
From a business perspective, we focus on features. What it will bring to our users? Why it will be impactful for the company? We want to satisfy the customers buying our product.

Time :
Time is interesting because it brings practices in the 3 other dimensions.
Time in the Runtime includes failure recovery, availability and logging.
Time in Artifact includes version control, and practices to avoid regression.
Time in Decision is about long terms vs short terms, and foresee what the market will need.


Maturity will improve with time

The difference may be huge between a mono dimensional and a multi dimensional developer.

The good news is we can (and must) improve with time, by learning in these different dimensions. It is normal to focus only on a few of them at first, but opening our mind to other dimensions will improve our skills as software developer.

We already have different names for these multi dimensional developers, depending on the dimensions they value. We call them Craftsmen, fullstack programmers, 10x engineers, DevOps or DDD practitioners and so on.

Do we give these names, because calling them “developer” suggests a mono dimensional person?



Thanks Brian Gibson for the feedback.