To become a software crafter…Or die in the attempt.

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.

One thought on “Coding in N dimensions

  1. Hi Emilien,
    I see you make two points in this post:

    – the need to account for time in the physics of software

    – the journey of a software professional in the 3 spaces

    About time: yes, it’s an important part of the model, that I didn’t have time 🙂 to cover at DDDEU or in old posts. I posted a short recap of my current perspective on Time here:

    (I’m not posting the entire text here as a comment because I’m trying to keep most of the info in a single place / few places; hope you won’t mind).

    You’re also absolutely right that the “best” software professional have mastered the 3 spaces well. Indeed, the ability to jump quickly from one space to another while talking / thinking about a system, and the ability to influence decisions by taking into account not only other elements in the decision space, but also the artifact and the run-time space, are both extremely important for senior developers. Actually, almost 11 years ago I proposed that the ability to move between the 3 spaces (even though I had no names for them yet 🙂 was the best way to avoid becoming a commodity:

Leave a Reply

Your email address will not be published. Required fields are marked *