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 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.
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.
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.
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.
