←back to thread

Do the simplest thing that could possibly work

(www.seangoedecke.com)
1096 points dondraper36 | 2 comments | 29 Aug 25 19:05 UTC | HN request time: 0s | source
Show context
boricj ◴[30 Aug 25 10:53 UTC] No.45073614[source]▶
I disagree. You prototype the simplest thing that could possibly work. Then, you design stuff so that you don't end up regretting it later.

I happen to have a recent example with an add-on card. For reasons that I won't get into, we needed both insurance against major rearchitecturing, as well as leverage synergy with other product lines when it comes to configuration. That led me to design a fairly intricate library that runs visitors against a data model, as well as a mechanism where the firmware dumps its entire state as a BSON document in a dedicated Flash partition before upgrading. That gave us the peace of mind that whatever happens, we can always just restore from that document and nuke everything else when booting a newer firmware for the first time.

The simplest thing that could possibly work would've been to not do any of that and let future firmware versions deal with it. Instead, I designed it so that I don't end up regretting it later, regardless of how the product evolved.

The only point I do regret was missing one piece of information to save on the initial release-to-manufacturing version. I had to put in one hack that if the saved document has version 1.0, then go spelunking in the raw flash to retrieve that piece of information where it was in version 1.0 and slipstream it into the document before processing it. Given the data storage mechanism of that platform, I'd be tearing my hair apart dealing with multiple incompatible data layouts across firmware versions if I did the simplest thing.

replies(1): >>45084392 #
froh ◴[31 Aug 25 16:24 UTC] No.45084392[source]▶
I think your version _is_ the simplest thing that works: software updates are part of what needs to work in embedded. else you brick devices and have to send technicians to the device, right?
replies(1): >>45086120 #
1. boricj ◴[31 Aug 25 19:14 UTC] No.45086120[source]▶
The simplest thing that would've worked was for the initial firmware to do nothing besides putting the new firmware in the secondary slot, tell mcuboot to upgrade and then reboot. That shifts the responsibility of working upgrades to later firmware revisions, at the cost of significant technical debt and extra development costs in the future.

My point is that the simplest thing that could possibly work disregards state and time as factors. Good engineers balance all requirements to derive the simplest solution that works; great engineers do so while avoiding visits from irate future colleagues.

replies(1): >>45124516 #
2. froh ◴[04 Sep 25 07:19 UTC] No.45124516[source]▶
having created a dependable a/b update for firmware (with failure detection and fallback), I can confirm this alone is a very very tricky challenge.

and I can confirm the good / great threshold.

my point is that given a high enough cost of "brick over the air", anything below great is not enough. think automotive, or any other industry where you need to send out field technicians to the bricked devices to fix the problem.

If it's affordable to ask a customer to put in say a USB stick into some specific slot and to download things themselves over the Internet, then the simplest thing that possibly works may not need the same complexity, I agree.

hehe, thank you for helping me getting this sorted in my brain. I have a strong tendency for making my problems even harder than they need to be. maybe this is exactly the point I'm at the: first figure how simple the problem is, before finding a fantastic solution for a problem that is more complex than reality requires.