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.
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.
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:
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.
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.
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 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.