[carlosjobim]

Very level-headed comment. I'm one of those who sees programming as a means to an end and nothing else.

If I order something to be delivered, I don't care what model of car the delivery company uses. Much less what kind of settings they have for the carburetor needles or what kind of oil they're using. Sure, somebody somewhere might have to care about this.

That's also how people like me see programming. If the code delivers what we need, then great. Leave it be like that. There are more interesting problems to solve, no need to mess with a solution which is working well.

[int_19h]

The problem is that "code delivers what we need" usually translates to "shovel crap as fast as it sells". Combined with heavy monopolization of the software market, where users have very little recourse to being force-fed crap - what are you going to do, go to one other competitor who does the same exact thing? - this means that average software quality in the industry has declined to the point where I would consider shipping it in that state to be actively harmful to the users and to the ecosystem at large (since others then build upon that pile of crap, which of course is a GIGO problem).

Now, you might argue that it doesn't matter because it's not the users who pay you, it's the company. But, well - some people have professional standards. It's rather unfortunate that this is apparently not compatible with "doing business" in this day and age, at least outside of very narrow niches.

[skydhash]

The things is most times, you are indeed buying the car that is going to make the delivery. And it's going to live in your garage. And if you're not careful, one day it will drive itself off a cliff, stall in the middle of a 10 hour drive, or you'll get robbed by individuals hiding in the trunk.

People that realize this care about their oil type and what tire they put on. People that do not, pay it forward when that crash does happen and they don't know how to recover, so queue up the war room, etc...

Even if you're not dogfooding your own software, if you do not take care of it properly, the cost of changes will climb up.

[carlosjobim]

> Even if you're not dogfooding your own software, if you do not take care of it properly, the cost of changes will climb up.

How do you mean? If the software works, then it's done. There is no maintenance and it will continue working like that for decades. It doesn't have corrosion and moving parts like a car. Businesses make sure not to touch it or the systems it is depending on.

[skydhash]

That would be fine if the dependencies were permanent. Hardware fail and need to be replaced. The OS will be upgraded (macOS is more than happy to make breaking changes). If the software is networked, that’s another transient plane. Libraries will fall out of support range.

Then there’s the fact that the user’s needs fluctuate. Imagine having to pay for a whole another software because the current code is spaghetti and full of hardcoded value and magic constants. It worked, but now you want a slight adjustment, but that can’t no longer be made unless you’re willing to rewrite the whole thing (and pay for it). That would be like having to buy a whole new car, because you moved to the house next door, as the car is hardwired to move only between your old place and where you work.

[carlosjobim]

In my opinion, the OS should not be updated. Not if important software is running on the machine. That's why we see cash registers still using Windows XP.

Sure, if you test it and see that there is no issue with updating, then you can update if you want. But neither the OS or the hardware or anything else should get any priority over the business-crucial software you are running. Even with hardware failures, the better option is to get older hardware for replacement if newer hardware has compatibility issues.