Best Practices Necessitate Context

Rosmianto from Embedded Systems Hobbyists to ProsOct 26, 2026

Best Practices Necessitate Context

Following best practices for the sake of it is actually poor practice.

Oct 26

Many embedded engineers treat embedded best practices like recipes in a cookbook. You follow the practices, and you get the benefits.

That’s true, only if you match the exact case and situation where those best practices were meant to be applied.

The problem is, more often than not, we don’t find ourselves in that exact situation. Here’s an example from NASA:

The first rule is pretty straightforward: ban goto at all costs.

So, ideally you shouldn’t use the goto keyword, right? Well, not if you’re Linus Torvalds. Because in embedded Linux device driver development, we often use goto for initialization and deinitialization:

It’s pretty much the opposite of NASA's #1 commandment.

The Linux driver model uses goto to create a robust cleanup mechanism. Many Linux kernel drivers need to perform a strict sequence to initialize a peripheral, and a strict reverse sequence to deinitialize it. So the code looks like this:

And apparently, goto really simplifies driver development.

Another example is microcontroller selection. I spent the majority of my career working in niche startup companies, so by nature our target market wasn’t that price-sensitive, but we moved really fast.

This week clients wanted Sensor ABC, next week we would have a new client wanting Sensor XYZ, and so on.

Given that context, I always recommend that embedded engineers focus more on hyper-modularity, testability, and extensibility (making it easy and fast to add features), even though you have to sacrifice binary size.

That’s fine because, in our context, flash memory is cheap. We can afford to switch from an STM32L0 to an STM32L4 for better performance and a bigger memory size.

Now, just imagine if an embedded engineer working at Omron (a medical company) heard my advice above and just applied my “best practice”.

The best practices won’t work.

The hyper-modularity will probably occupy 150% of the microcontroller’s flash memory. Changing the microcontroller won’t work either because a $0.10 increase means adding $10,000 in cost to their 100k units.

So, before you Google or ask AI for the “5 best practices to develop efficient firmware”, understand your context first. Filter the advice, and then throw out the irrelevant parts.

Power to you,

Rosmianto

PS: Btw, understanding best practices with context is where I see AI still failing a lot. I often get AI-generated code literally mixing Arduino-style code with automotive-grade code. It doesn’t look right. It’s weird.