Hardware has a reputation for being hard for three reasons. First, it scales differently than software. It's far harder to design something you want to make a million of than something you want to make ten of. Second, it's harder to anticipate, test, and correct all the things that can go wrong on the user end. Some people will put batteries the wrong way, some will drop the device on the ground, some will connect it to some vintage equipment you have never seen in your life, etc. And third, there are just more failure modes in an unfamiliar domain - sometimes, your code will intermittently crash not because you have a software bug, but because you put the decoupling capacitor too far from the chip. Or, just as you finish your design, the chip you designed it around becomes obsolete, or impossible to find because a factory in Indonesia is on fire.
Another complication is that at least in theory, if you're selling electronics, there are actual regulations and third-party testing that needs to happen, and if you fail emissions, you might have to redo your design from scratch. Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".
So, I'm happy for the author, but I think he had an outlier experience. When you look at Kickstarter stories, people repeatedly stumble over this. Manufacturing / cost difficulties, supplier issues, reliability issues, etc.
>your JS is too big, you can't ship until you get it under 50 kB
Back in the glorious past, the iOS App Store either didn’t allow apps larger than 100 MiB, or at least forbade them from being downloaded over mobile connections. There’s an old blog post/Twitter thread you can find on Hacker News where an Uber engineer describes the challenges they faced in trying to keep their app under that limit. They were also rewriting the app in Swift, so some compiler patches were necessary.
> Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".
We’re one decade into cookie banners and privacy regulations by jurisdiction. There’s some vague similarities with interference here.
>Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".
A man can dream.
> Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".
dont threaten me with a good time :)
Firmly agree. A lot of the lessons you mentioned have been discussed previously on HN threads for hardware startups. This is one of my favorites:
https://www.simonberens.com/p/lessons-learned-shipping-500-u...
Yeah, I think a lot of the "hardness" of hardware is of a different flavor than software. The author mentions how many lines of code are in the software, but that really is more of a symptom of something that makes software "easier": you have way more flexibility to iterate, and try new things, at a relatively low risk and cost, even if it's embedded software (at least for non-critical applications). Hardware is just more unforgiving. There's no cheap way out of the kind of scenarios you mention.
Microcontroller and sensor bugs owe me a lot of sleep that I will never get back, to add to your point.
>> Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB
I work in games, we run into this problem all the time ("Your IPA binary is too big, fix it and resubmit", ditto for other publishers).
Maybe this isn't special in the era of pre-funding but there's also over manufacturing. You have to guess how many you'll sell. If under guess you leave sales on the table. If you over guess you lose money to all your undersold but already paid for inventory.
> Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".
... But also that needs to be an official measurement, and if you're sloppy you can measure it wrong during your own testing and then be surprised.
> impossible to find because a factory in Indonesia is on fire
Has that happened to you?
Then something has to be said about digital/discrete hardware, which is not dissimilar to programming, and then the alien (to software devs) world of analog chips.
> Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".
... that's a very normal constraint in many fields of SWE?
>your JS is too big, you can't ship until you get it under 50 kB
Not only that but every single update you push requires paying $$$$$ to get certified. It is freeing that the cost of releasing a fix or improvement to a product is $0.
In the past I considered selling a custom adapter to hobbyists, but all the certification costs just did not make it a viable option to pursue. I didn't want to up front thousands of dollars to make like $100 if I was lucky.
[dead]
> "actual regulations...emissions"
yeah, and looking at their board I see they use one of "ESP32-WROOM" modules, which has the wifi & blutooth & antennae (pre-certified by Espressif for FCC, CE so itself doesn't need testing) & flash & processor (which even has its own RC oscillator), which takes care of a whole ton of difficult stuff so all the designer needs to do is plop that module down and power it up and wire some SPI/I2C peripherals which I'm guessing don't need super fast clocks or electrical constraints. Without something like those ESP32 modules, this would be much more difficult.