Building software for the moment that cannot wait

Building software for the moment that cannot wait

Working with Propellerhead has been one of the most eye-opening experiences of my journey as a developer.

I came in thinking I understood what transport software looked like. I was wrong, in the best possible way.

When we think about public transport, we imagine buses, trains, and schedules. What we rarely see is the invisible layer of software operating behind the scenes, processing, validating, and distributing information in real time under strict timing constraints.

In transport systems, a few seconds of delay is not just a delay. A late vehicle update can break a passenger information display. A delayed signal can cascade into operational decisions based on outdated data.

In this world, software does not only need to be fast. It needs to be predictably fast.

That is a completely different engineering challenge.

What real-time actually means

Through my work on vehicle tracking systems, I have come to understand real-time systems in a very concrete way.

We process live position data for buses, trains, and ferries continuously, second after second, delivering it to control centers that depend on accuracy and immediacy.

If the data pipeline slows down or fails, operators lose visibility. Decisions become unreliable. Operational impact follows.

Real-time is not about raw speed. It is about consistency, determinism, and reliability under pressure.

The control center needs to know where a vehicle is now, not a few seconds ago.

A delay is not just a technical issue. It becomes an operational one.

From earth to space, the same foundations

What fascinates me is how universal these principles are.

In my free time, I explore microcontrollers, embedded systems, and satellite communication. I try to understand how spacecraft manage timing, power, communication, and fault tolerance, often without any possibility of human intervention.

The more I learn, the more I see the connection.

Transport systems and space systems operate in different environments, but they share the same core engineering principles.

Deterministic behavior. Resilience under failure. Reliable communication. Strict timing guarantees.

A bug in a passenger information system is costly. A bug in a spacecraft hundreds of kilometers above Earth is irreversible.

The scale changes. The fundamentals do not.

Rovers are driving on Mars. Spacecraft are crossing the solar system. Software is making all of that possible.

Solving transport problems on Earth and thinking about space systems are not as far apart as they seem.

Why I keep coming back to Rust

Years ago, during my time as a Mozilla Ambassador, I discovered Rust.

At the time, I appreciated its strictness and design philosophy. Today, I understand its importance more deeply.

Memory safety without a garbage collector. Compile-time guarantees that eliminate entire classes of bugs. A concurrency model that makes data races extremely difficult to introduce.

In systems where failure is expensive, whether that means a wrong display at a bus stop or a failed satellite communication, you want tools that prevent errors before they happen.

Working in transport environments made that reality very clear.

Rust’s ecosystem for embedded and real-time development continues to grow stronger, and it aligns deeply with the type of engineering challenges I care about most.

I am curious to hear from others working with real-time constraints, embedded systems, aerospace, or other domains.

#RealTimeSystems #EmbeddedSystems #Transport #SpaceTech #SoftwareEngineering #IoT #Rust

Excellent insights. “Real-time is not about raw speed. It is about consistency, determinism, and reliability under pressure.” This principle goes beyond transport. In payment space it is the same thing.

To view or add a comment, sign in

More articles by Jonathan NENBA

Others also viewed

Explore content categories