Software has a problem.
OK, it has many problems. I’ve already highlighted one of them. But this is another important one.
The problem is that software—all software, with no exceptions—sucks. The reason for this is multifaceted and we could spend years and years arguing about who has the larger list of reasons, but in the end it boils down to the proverbial shoemaker’s children: Our development tools are the worst of the worst in software.
F/OSS is not the panacea its advocates claim it to be. I mentioned collecting bizarre compiler bugs. GCC has a huge presence in my collection.
And this ignores the fact that F/OSS often has no presence whatsoever in entire industry swathes. F/OSS, for the most part, with some exceptions, lags behind the technology curve when it comes to bleeding-edge tech. This is sometimes the fault of vendor shenanigans (I’m looking at you here, Altera and Xylinx), but often it’s just the problem of a very specific problem domain with very few eyes willing to work on it as a hobby.
Why do people always confuse FOSS with hobbyist software? There’s lots of commercial FOSS out there, some even with a sane ecosystem.
For example, the PlatformIO IDE is part of a larger, commercial ecosystem. Open Source allows a code and architecture audit before spending a single cent.
Because a lot of it, even when “commercial” is hobbyist-grade at best.
PlatformIO being one of the ones I’d place there, incidentally. Failed out of the box for me (where “fail” involves “crashing”) when I tried it, resulting me in spending more time debugging my tools than my own code. Which is exactly what I rail against in this article. Even this reeks of hobbyist work:
That focus on “boards” and “dev-kits” is basically useless for people who, you know, are making their own hardware. (Like my employer.) By the time you navigate through all that (often poorly-written and invariably poorly-documented) crud it’s actually cheaper, in terms of development time, to write it from scratch in-house.
I genuinely gave PlatformIO a try for a work project. I had to ditch it and replace it with a hastily-assembled ST HAL-based from-scratch project to get it done in time for the test cycle. It’s simply not suited to the use cases I have both because of the crashing issue and the way hardware support enters the picture (which revolve around 100% custom hardware in our shop).
Had the first issue not been there, I might have had more patience for the second one (and vice versa), but the two together made it a show-stopper and added to the long list of shoemaker’s children.
Isn’t platformio just a GUI for gcc/clang, gdb/lldb, some flashing-tools and vendor libraries?
With my (embedded) work the most problematic software is always of the proprietary kind. The worst part is that I can’t even realistically fix any problems I stumble upon! I have terrabytes of VM-images only to be able to keep that stuff running in case I need it again in the future. I sure as hell wouldn’t want to pay for that experience. (My clients do if they insist lol)
The only way to make software slightly less shitty is to reduce complexity, have proper specifications, try to test every assumption anyone has at any point and be incredibly conservative in how and why you introduce new features. This is infeasable for most businesses (currently?), especially for one that has a very niche group of customers.
The focus on dev-kits I think is increadibly annoying too, especially since it’s not rocket science to get simple microcontrollers to run. (For FPGA’s or SoC’s having a reference design to steal from is pretty useful though.) The time some vendors spend to get arduino, micropython some display-demo or whatever bullshit running on their dev board would be better spent writing better documentation 100% of the time.
Well first, it’s not “just a GUI”, it’s a layer slathered atop the already very broken VSCode. Or, rather, PlatformIO GUI is a layer slathered atop VSCode that puts a GUI front-end over PlatformIO Core (a CLI environment). This core itself tries to thread together a bunch of libraries and frameworks into something resembling a coherent whole, but fails at that task because support of each of these frameworks and libraries varies highly in quality, and by the time you unravel that entire mess you could have already finished your application if it’s a non-trivial one. (As with a lot of popular tools, trivial applications can be a button push away, practically.)
In the end it was easier to drop PlatformIO in the middle of a project and rewrite from scratch without its meandering mess than it would have been to keep playing the sunk cost fallacy game.