I think about software reliability a lot and try to generalize failure causes (I have about 30 years of experience designing and building systems). While I do

I think about software reliability a lot and try to generalize failure causes (I have about 30 years of experience designing and building systems). While I do have a number of top bug-causing patterns, the above comment is spot-on: unnecessary complexity, while not being the direct cause of problems, almost always comes up when analyzing failures. You have a much better chance of getting your system right if you avoid complexity. If you want practical real-life examples: many engineers when building a small embedded device will use a Raspberry Pi or something similar that runs Linux. It's easier for them: they get a full OS that they are used to, there is Python, all familiar. And yet, quite often all this is overkill for the task at hand, which is monitoring temperature, or controlling a bunch of GPIOs. You pull in a humongously complex stack of software, with thousands of quirks, bugs, and quite a bit of emergent behavior that no one understands, even though the task could have been performed by a bare-metal program running on a microcontroller, or (if we want convenience) running under Zephyr.