What This Article Is About

When reading all those posts here by business people, consultants, trainers, coaches, you can hardly avoid the impression that developers, engineers, technicians are considered emotionless animals. The opposite is true! Almost every serious developer feels a deep love for his favorite tools. That’s where the dangerous part is beginning: Do we want to chose a toolstack, a programming language, according to a developer’s love?

Risk Domains

Until recently the world was well partitioned: embedded development, server programming, app development, web development. Every space with its relevant players, specific specialists, philosophies, tools. Since the emergence of the Internet of Things these domains are no longer separated. A company offering an IoT product is required to deal with all of them at once. So the widespread question „Which programming language do we want to chose?“ is going to be replaced by: „Which language for which domain?“ (Note: Feel free to replace the term „language“ by toolstack, platform, etc., just according to your needs).

It’s always a good strategy to look at the beast from its tail. What do we want to achieve? We want to avoid failures, which means we need to control the risks inherent in our IoT chain. Interestingly, risks are very different depending on which part of the data chain you are looking at:

• At the edge device, a crash is usually inacceptable. A crash will cause loss of data, and the super-hero run at the local triathlon is lost forever.
• The same is true for the transport of data up to storage in the database („cloud upstream“). If something is faulty here, not just our super-hero will lose her data, but maybe thousands of other users as well.
• The „cloud downstream“ situation is completely different. Imagine our triathlete’s app will crash in the evening while she’s showing her run to her friends. She’ll definitly be okay with reloading the page and give it a second try – as long as her data is safe.

Let’s stay for a moment with the last item. Reliabilty and stability seem not to be the major issues here – Bill Gates and Microsoft taught us fault tolerance for decades. What’s really important here? If you want to have a competitive edge, you need your features earlier than your competition has them. It’s time-to-market (TTM in the figure above). In other words: Our major risk here is being late.

Reliability, Stability, Speed

When developing a solution (or a part thereof), we usually move from the idea via a (mostly) feature-complete, but buggy, version to a mature state.

Pareto told us that we will achieve 80 per cent of the desired result with 20 per cent of the total effort. Pretty much the same is true for the relation of a working solution to a flawlessly stable solution. Given the risk domain partitioning above, you will probably invest the whole budget into a really stable edge embedded software, while you will give in to your manager’s pressure for fast release after having a working solution for some new feature of your web app.

Choosing The Best Approach

We need to state that the „Pareto“ picture shown above only gives us relations. It doesn’t tell us anything about the absolute time required. Even worse, the relation between a working and a stable solution may depend on the tool we are using.

For example, comparing C and RUST, average developers will need more time to get a working, feature complete prototype. They will have to deal with all the restrictions of RUST concerning memory management even during the first draft. But later on, they will benefit from their clean code and reach a stable release much faster than the heavily debugging C developer.

Hence, for a risk-sensitive area with high demand for stable and reliable code, you will want to prefer RUST over C (or Java, Python, …). The other way round, if speed and time-to-market count, you simply cannot afford to design your code according to RUST’s rigid expectations. You will probably chose Node JS and a toolstack like React to provide a fast and just sufficiently stable result (regarding C, see the following sections).

The Real World is Embedded. And Human.

While we now know what we want to chose, can we actually make the right choice? Obviously, from a risk assessment point of view, you will no longer want to start an embedded development in C. There are two reasons to consider C nevertheless:

Most importantly, the supprt for RUST in the embedded space is still emerging. While there is some, partially even good, support for some microcontroller cores, the handling of communication stacks like bluetooth, thread, etc. is a nightmare. Unfortunately, SoCs integrating an application controller with a radio stack become more and more prominent and important.

Secondly, there is the very experienced embedded C developer in your team. This is the human factor. He simply does not want to change his mind. You’ll certainly have to address this risk.

Conclusion