that's actually, um...common? i just had to repair an electric jackhammer last week. i worked in a machine shop for a large well drilling company not long ago, and not only did we create/repair tools for the company, but obviously had to keep our mills and lathes and cranes, etc. in good working condition.
It's not common in the same sense. First of all, tools are very different from software products. And there is never the same level of analogy that one has to do in software.
Imagine buying a hammer, that hammer not working, the hammer's design being so complicated that it's impossible to understand or mend, and then having to design and build your own hammer, and then putting up with that situation over and over again and accepting that as the status quo. That would be the correct analogy.
I'll agree wholeheartedly that the analogy needs some work. Tools are different - we have our literal physical tools that we don't generally dive into (keyboards, mice), we have tools that are maybe more battle tested and rarely examined (cat, grep, find).
We have do have tools like the hammer - there is one design, everyone more or less agrees on it. There is still high quality and low quality, but it has one job. We have tools like a bulldozer - complex, numerous parts, requires constant maintenance, closed source.
As the parent said - it is not uncommon to have to maintain old equipment, as well as design new tools as new requirements pop up.
Sure, our rust is a little bit different - time wears on software in a different way. Use wears on software differently. (Changing product requirements leading to a new tool is probably common.)
The maintenance may be trickier - but I'm sure changing components on a tool when a certain component is no longer available is not easy, thats where shim layer comes from!
Have you met farmers? They will readily tear apart their equipment to fix an issue or modify the tool to make them more ergonomic. This trend of massive multi-million dollar John Deere combine harvesters with DRM widgets that you need to take to a specialized tech to get fixed, is a relatively modern one, and one detested by virtually every farmer.
This was and is quite common in any blue-collar field where works don't always have the money or time for a brand new jawn every time something goes wrong.
I love estate/yard/garage/barn sales and going through the tools and reading the tales they tell from their wear patterns, field repairs, revisions, and hacks from their owner.
I worked on a farm. I think the things you're bringing up are still subtlely different. Modifying something you can see and touch for some unintended purpose versus modifying some piece of software because it doesn't work are miles apart from each other.
For example, I have a graphics project where screen tearing suddenly started appearing although my code didn't change, and the tearing wasn't there before. Is the issue in Skia, OpenGL, the graphics driver, the Intel or NVidia GPU, or the OS? Or is it some latent issue in my code that started showing up because of a change in these dependencies? Or is it some other complex interaction between multiple dependencies? I couldn't possibly know, and I actually don't think there is anybody that actually knows. And there is zero chance I could ever figure it out. I mean, it at least appears it was a driver issue as after some updates and a reboot it just went away, but there is zero insight into why or what actually made it go away.
If I modify a plow because some part as originally designed was flaky and constantly broke, you usually know to a pretty good degree why your fix works.
In software, the abstractions are such that it is practically impossible atbtimes to understand.
That to me sounds like a difference of degree or heap problem, rather than a categorically different condition.
Sure, welding back on a hardpoint that broke off a plow is concrete and obvious (maybe that's analogous to fixing a broken dependency that got renamed), but there are other fixes that definitely fall under "I don't know why it works but it works". I've had electrical gremlins and fixed them by grounding something that looked like it ought to be grounded, and was grounded when I tested for continuity, but nonetheless was acting floaty. It was probably a loose connection elsewhere in the system, but I didn't know that for sure, nor do I even know that it was the problem in the first place.
Software definitely reaches insane depths of complexity, but again, if you can dig down and understand the abstraction well enough to attempt a fix, and the problem goes away, isn't that good enough? The real difference is mechanical systems typically only have a few layers of abstraction, while software has dozens to thousands of layers of abstraction.
I feel like this is quite common but it depends on the optics of situation.
A mine site usually fixes its own tools used to do their job, they usually fixed things they've purchased to use that are broken or become broken, is that not the same?
Your job as a developer is to write code and piece code together to make your life easier. That includes taking the work that others have done and make it work to suit your code base.
On a mine site, the job is to mine and process minerals. That includes engineering a mine using products that eventually fail over time and need fixing. As part of that process an automotive electrician may need to fix the electronics on a vehicle that have become faulty or damaged.
Mechanics and engineers need to inspect, rebuild, and fix the tools they are given to do their job. The difference is that yours may not work up front, whereas these tools need maintenance over time.
When I was doing enterprise work with closed-source libraries, any defect required them fixing it. We've found some issues with AWS and they fixed it too.
The difference between most professions and programming is that we have open source. The equivalent of that in the real world is getting blueprints to build our tools and then building them ourselves, with no guarantees.
