A general programming discussion community.
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
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 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.
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.