To go further than that, embedded projects more frequently than not have one and only one software developer. It's not like building a website with a team of s

To go further than that, embedded projects more frequently than not have one and only one software developer. It's not like building a website with a team of several developers. In this context the "nobody" in your scenario is the only person on the project. Which, once again, brings us to the idea that it isn't the language or procedural vs. OO at the root of the problem at all if things are done wrong or misused. I must also point out that hypothetical examples are rarely meant to cover all possible scenarios, much less corner cases. They are simplified examples to facilitate an explanation. As such it is always possible to find holes in the hypothetical. A colleague taught me a very important lesson about twenty-five years ago. He was about ten years older than me and had far more experience. I had just finished coding an electronics component management system for our manufacturing department where we worked. It was really slick and fast at a time when text-only apps and menus reigned. I was proud that my six month effort had produced such a product. I was showing it off. When it was his turn to be dazzled he let me do my "look at this" tour of the software and said virtually nothing. When I was done he said "looks good" and proceeded to plant his palm on the keyboard and run it back and forth about four times, pressing as many keys as he could at random. The program crashed and he walked away. It took me about a month to make it robust enough to have it react gracefully to such an attack. Learned a lot in the process about dealing with the real world. This gave me the mindset to write code defensively. A function such as "set_immediate_rpm()" should be bulletproof, and this has nothing to do with OO vs. procedural. A good implementation of "set_immediate_rpm()" would have a rate-of-change evaluation such that you could call it a million times and yet not violate the maximum desired rate of change (presumably set through a different function or defined as a constant somewhere).