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.
This is mainly software for hardware and driver development. Yes, it sucks. The routing software and proprietary tooling from all the IC manufacturers suck, too.
It doesn’t surprise me the author bought stuff for thousands of monetary units and it was still shit.
Weirdly enough, I found that the Open Source variants of said software (e.g. KiCad or the PlatformIO IDE) are way easier to use and more stable than their commercial counterparts.
If the author spent the same amount of money on FOSS tooling, it would be better for them and everyone else.
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.
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:
Multi-platform Build System without external dependencies to operating system: 50+ development platforms, 1000+ boards & dev-kits, 20+ frameworks. Arduino and ARM mbed compatible.
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.
This article lack the answer to a fundamental question. What’s the definition of “software sucks”?
Then it start with " the bike shop has good tool" . does it? There are obvious limitations to the tools available, some breaks wayyyy too easily, there are competiting standard , backward compatibility issues, sometime the bike break instead of the tool, ect.
Moreover bike mechanics do not have the skill set to build their own tools from the ground up. Programmers do.
It seems that the author has a romantic notion of programming and the world in general.
The problem is more profound than what the author implies. Inother disciplines tools are made of something else or by an entire discipline. While software is made out of other software.
For examples, bikes tools are not other bikes. One does not fix a bikes brakes holding another bike in his hands. While a software 005757. So debugging the debugger involves yet another debugger or in the best case, the debugger itself (dogfooding).
In a bike ship, if my wrench gets bent, I need knowledge in material and heat treatment to make a better wrench. In software, if if my debugger sucks, I need knowledge in debugging software, and guess what,theat debugger sucks more because it is at a lower level.
Concrete example. I want to build a web app and use my favorite JS framework. Things generally work well and I use the browser own developer tool to debug. If I see something wired, I need to get down a level and see what webpack or any processing tool I use does to my code. Which is the same process of debuging juste a bit different.
The tools used in forging steel tools are made by forged steel. There are different skill sets even in foundry-oriented metalwork.
I know this goes against the grain of software developer ego, but there are actually very different skills involved in various types of software, and someone who can churn out a CRUD-backed web page at the push of a button (often almost literally) is not going to be making an optimizing compiler anytime soon, while the compiler writer may look at the utter screwed-up state of web programming and recoil in horror, not knowing where, even, to begin.
It’s great for the ego to say “it’s all software, so because I can write a <insert trendy web framework here> app, obviously I can write an operating system too”. But it isn’t true.
While what you are saying is true, I disagree because forging steel is not performed for the sole purpose of forging steel. Forged steel, while being the end product of some factories, it is never meant to stay like that, but to be further processed. At least cut in sheet and soldered somewhere. And honestly making a sheet of steel is much simpler than making a wrench. And the order of complexity magnitude between making a sheet of steel and a wrench is certainly not the same as making a compiler and building a website with Go/Node/PHP or anything.
You think most programmers have the skill set to build their own compilers, debuggers, operating systems, etc. from the ground up … and I’M the one with a romantic notion of programming.
Most people who call themselves programmers think that “full stack” means Javascript on both the server and the client. Think the best way to program is to go to SO and cut and paste code snippets. These people cannot build their own tools from the ground up. They can barely get a CRUD-backed web site up and running.
Oh irony of ironies, today is a perfect example of what I’m alluding to in the blog. I was unable to post this all day today because the recent server update caused some problem with a component that Lemmy uses for pictures.
Software sucks.
Note, I’m not trying to drag Lemmy’s programmers here. They can’t help the fact that the software tooling landscape is a wasteland. They’re the victims in this, not the perps.
Many use cases, many hats. Most of us play multiple roles in our lives, whether we know it or not – and so wear multiple hats.
We’re all victims, to a degree, of poor software design, and we’re all responsible for it to a degree as well. If for no other reason, because we make some compromise for some other perceived gain. We literally enable bad software every time we use it.
Thinking of you here, Google, and your compatriots Facebook and Twitter.
Not just to be argumentative, but rather to suggest that there is something we can all do about it. Even those among us who are not programmers or engineers can raise awareness among both other users and service/software providers, and refuse to use bad software and crappy insecure web technology.
One thing we can all do (users and practitioners both) is STOP ACCEPTING EXCUSES. Buggy software is broken software. Period. Shove this in the practitioners’ faces (and accept that it will be shoved into ours!) and stop standing for it.
One of the reasons we in this industry have gotten into this state is that we’ve convinced the public (and ourselves) that this is normal. We’ve shot ourselves in the foot for so often that we think walking around leaving bloody footprints behind is normal.
And we’re about the only branch of “engineering” (scare quotes because I can count on one hand the number of software makers I think use engineering principles–and I don’t number myself on that hand) that tolerates the kind of cowboy bullshit that is normal. Cowboy civil engineers get sued to perdition and/or jailed when their output is fundamentally broken. When mechanical engineers make broken shit, they go bankrupt from the returns. Yet when software “engineers” product total and absolute shit they get away scot free and, indeed, they often, bizarrely, manage to sell the repairs as “new software”.
Excellent commentary. Excellent use of markdown for emphasis. 5/5
Excellent evasion. Truly stupendous pedantry. 5/5
Evasion? Pedantry? I’m afraid you’ve lost me. In any case it seems odd you would adopt such an acerbic posture with someone who essentially just agreed with you right down the line.
Go figure.
Yes. Your reply was not even slightly sarcastic and was clearly supportive. My bad.
I don’t think it’s the right general solution, but the solution to the specific problem framed by the OP is software as a service. You get a free trial, then you pay monthly, as long as you continue using it. So the developer is incentivised to make the software work properly.
Software as a service has its strengths but has more weaknesses from the perspective of someone trying to base their own business model on it.
If compilers were SaaS, for example, there’s no way to make stable, confirmed firmware. (Hell, it’s hard enough to do that when you in theory control your own software!) For some sectors (like the sector I work in) this is an absolute necessity. You can’t have a sudden change in the compiler happening out from under you making your firmware’s hash value different and thus requiring another (expensive!) round of verification.
And this doesn’t even count the problem of using a third party’s continued existence in the core of your own business. My employer owns the IAR seats that it has. (Does IAR suck? Of course it does! Have you not been paying attention!? 🤣) If IAR go out of business tomorrow, we can still do our work because the software is on our machines. If we SaaSed our tooling, we’d be fucked when a single vendor goes under, along with their servers.
If there could be some way to guarantee stability of SaaS, both in terms of release management and in terms of persistence beyond the scope of the company offering it, SaaS could very well be a way for companies to be forced into upping their game, but I personally can’t even envision the solution to those two critical problems.
Two dimensional, one dimensional…you can make a bijection between Z^2 and Z, so who cares? There is still structure in one dimension.
You can replicate every computational operation in every computer with only NAND gates.
Ever notice how we don’t use only NAND gates?
Yeah, that.
“Can” ≠ “should”.
Computers are made up entirely out of CMOS transistors, which are all basically identical. It’s just in their organization and structure that they become interesting. Similarly, it’s alright for coding to be made up of simple characters, it can still have structure.
And another missed point.
Digital computers are made up of switches. (Not necessarily transistors, and those that are are not necessarily CMOS.) But nobody programs them as a pile of switches because that’s an insanely stupid level of abstraction to view problem domains through.
In the very, very, very early days of computers perhaps this was done, but that rapidly grew unwieldy and we developed ever more and better ways of organizing things so we could focus on problem domains instead of the minutiae of which switch was pointed which way. Sure enough, underneath all that there were still a myriad myriad of switches flipping on and off, but not a single programmer knows which switch is pointing which way beyond the grossest of levels (like GPIO pins).
Our problem domains have ballooned in complexity from the early days of programming languages, but our programming languages have not kept pace. We are spending more time on minutiae of testing, branching, and looping than we are on problem domains in our code, and complicated relationships in particular are difficult to model without extensive, error-prone effort in single-dimensional lines folded up into bizarre structures of tests and branches.
(This is, incidentally, something that was an active area of research in the 1970s. Computing power and computing complexity has risen exponentially since then.)
As programmers we are doing the equivalent of using a screwdriver as a chisel while building a house. (And, worse, using that screwdriver as the only tool for the whole project.) It’s not a wonder that our work is slipshod and filled with error.
Abstractions are important, but we don’t need to reinvent computing to support them…modern programming languages allow basically limitless amounts of abstraction. Have you ever used a high level library like PyTorch? You can define a very powerful neural network in less than 100 lines of code. You get to focus entirely on the architecture of the network (number and types of layers), and it handles everything beneath the surface: Calculating gradients, iteratively updating weights, etc. Even if you choose to define your own custom layers, PyTorch can automatically calculate the gradients of arbitrarily complex functions you compose yourself. Python (and many other langs) are extremely flexible.
Human language is “1D” by your definition, but you can still use it to talk about very high level ideas.
