Poetry buried in technical complexities
On my professional life, I have to deal with complex systems.
“Complex systems” is the fancy term for those systems with many interconnected components, where each component's behaviour is impacted by and, simultaneously, impacts other components' behaviour in a non-trivial way. The multiplicity of components and their interactions is what makes a system complex.
Buried inside those systems, there are beautiful design patterns, which might well qualify as poetic.
The coordinated embedded computers in any modern car are a good example of the aforementioned complexity.
Different subsystems in your car rely on embedded computers with varying degrees of sophistication. Those computers “talk” to each other through different communication buses (CAN Bus or LIN Bus, or both).
These computers serve different purposes. Their criticality level and therefore their requirements—both functional and non-functional— also differ. The electronic brain behind a car's infotainment system, for instance, is quite different from the one controlling the breaking system or the fuel injection. The latter type of computers fall into the field of safety critical systems, with which I have some familiarity.
There are general requirements that any safety critical system shall meet:
- It shall not fail.
- If it fails, the failure shall be unambiguous and informed to the impacted systems shortly after it occurs.
- When it fails, it shall do it gracefully.
The requirement that the system shall never fail is the ultimate, yet unachievable, goal. That's why the second and third requirements exist.
Unambiguity regarding the failure is crucial. The term “shortly after” is, usually, an explicitly defined time boundary.
Failing gracefully, on the other hand, is not well-defined. However, any experienced engineer working on safety critical systems has a strong intuition about what gracefully means in the context of a system failure.
Now. There are many design patterns in safety critical systems. Some of them are very simple, and their beauty partially comes from their simplicity.
For instance, many of these computers broadcast a message containing an integer number at regular intervals. That number increases by one each time. The first message, zero, the next, one, and so on. That's it.
There is no meaning for that number, the only requirement is that it increases each time.
What is the purpose of broadcasting a meaningless number at periodic intervals to the network?
Well, it is a computer telling other computers: “I'm alive!”.
“I am alive, and doing what I suppose to; do not worry guys, all is good.” Something like that.
If you store this number in a 64-bits unsigned integer variable (and you should!) and increase it, let's say, every 60 seconds, the variable overflows after ~35,096,545,041,304 years (you can double-check the maths, it was a quick calculation). So, the variable can easily outlive any physical system hosting it.
This variable is, most likely, buried in the code running somewhere in your car.
The hard problem of naming things
There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton
And if you're in the mood for some geek humour, Martin Fowler collected a few variations of this phrase here.
Indeed, one of the biggest problems in CS is naming things. Hard to believe when you're a newcomer in the Software's guild, but true.
You could write code as a mathematician. It works fine for simple programs or under specific scenarios. Call a variable x, another variable y, then z. What's stored in these variables? If you ask me, I would assume those variables store a 3D coordinate, or values of a well-known formula which uses variables x, y and z. Otherwise, the code would be confusing for me.
Inexperienced developers often fail to understand that code is written by humans, for humans. And, as humans, we understand the world through stories. So, for gods’ sake, name things properly!
When I read a new code base, I want to read a story. A properly written story allows me to understand the system quickly and therefore, add, remove and modify features efficiently.
If the story is confusing, it would take me a while to make changes in the system, and most likely, I would break things on my first attempts because a sloppily told story is often misleading.
That's why, when doing software design, I attempt to craft a story to be read by my future self or any other engineer who needs to touch the code at some point.
It takes a while to understand the importance of this.
As an engineer, you need to have good mentors to get it, as I did. Then, eventually, you must mentor others. Folks, please, name things properly.
Now. Do you still remember the variable storing a meaningless integer number which is periodically broadcasted to other computers? Did I mention the name of such variable?
It is called heartbeat.
Don't you find that name beautiful? Poetic, even.
If something is alive, its heart ... beats at regular intervals.
That meaningless number now has some meaning, the number of heartbeats(!)
If you're not a developer, some clarification might be necessary. That variable does not have to be named like that, but it is a commonly used name that many developers use. Someone, somewhere, somewhen used that variable's name the first time. Then, someone else read it and thought: “this is a good name”, and then, re-used the name. Somehow, it is now a commonly used name.
Who named this variable as heartbeat for the first time? We don't know (or I don't, at least). And it does not matter. It helps to craft a coherent story, that's why it is used once and again. Besides, history is full of unknown inventors and heroes.
So, Computer Science, Poetry and Story telling are somewhat related, believe it or not.
I believe so, feel free to disagree.