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.