[iso1631]

I wrote some software nearly 20 years ago, haven't touched it for over a decade.

The code was terrible, but I don't care, it did the job, and people still use it despite a whole team of people who have tried to replace it with "elegant" code in frameworks which have come and gone.

The reason people still use it is that it solves their needs, not the programmer's needs.

The goal was to make the user's life better, not to make a work of art

[customguy]

All you're saying is that for you only the destination ever mattered. But it's very apparent that is not true for a lot of people.

And "solving needs" is kinda vague. We drank from lead cups for a long time, because perfect knowledge of material and biology was secondary to just having a cup. And no single sip from any lead cup killed or maybe even much harmed any person, but it all added and adds up.

Of course the comparison with lead is kinda over the top, but it's just to illustrate the principle. If your software crashes the computer 1 out of 1000 runs, and it otherwise crucial and unique, people will still use it, and the longer and the more people use it, the more human lifetime it "destroys". If it would take you 1 year to find the source of the crash, it may not be worth it, if it would take you 30 minutes, it might be. You just won't get recompensated for it, you'd have to get satisfaction from it via something like craftsmanship.

Your users don't know either way, so it's your job to know. Saying it's not, everybody just has to be content with the transaction, is a bit like saying a doctor doesn't have to do medicine according to what they know is likely best, but according to what their patient thinks they need.

[iso1631]

And it is true for a lot of people. It's also true for the people paying my salary.

If you're making a plane, crashing 1 in 1000 times is terrible, if you're making some administrative thing which if it crashes costs 5 minutes work then it's likely fine

But you're still implying that the fancy software crafted by hand is better.

I have handmade crafted products and I have assembly line products. Not only are the latter cheaper and more consistent, they're often better. I don't want my beer to come in a handcrafted artisan glass while I'm watching the football, I want it in a pint glass of a known size and quality.

[customguy]

> If you're making a plane, crashing 1 in 1000 times is terrible, if you're making some administrative thing which if it crashes costs 5 minutes work then it's likely fine

Yes, and if it doesn't crash it's better than fine. Objectively.

> I have handmade crafted products and I have assembly line products. Not only are the latter cheaper and more consistent, they're often better.

Completely ignoring the care and work that (ideally) goes into making and running the machines at assembly lines, and the cleaning that takes place every day, or sometimes several times a day, all the strict regulations. You cannot compare 99% of software engineering with food production in modern countries. Similar for furniture, it can hurt or even kill, and it would do at a much higher rate if it was made like most software is.

There's gross factory food, and super nice street food, there's healthy factory food and super gross street food. That has nothing to do with anything. All else being the same, you want the person who prepares your food or runs the factory to pay attention and not be sloppy, or you end up with food poisoning, glass shards, and other fun stuff. You just take allll of that for granted, instead of imagining how awesome computing could be if the people involved in it took it similarly seriously instead of just applauding their own laziness.

[iso1631]

You're making an assumption that

1) spending more time handcrafting the code makes it less likely to crash

2) That the cost of the crash is more than the cost of the artisinal crafting

[thinkindie]

It’s not just the destination - there are infinite shades of caring too much about every single line of code (spaces! Tabs! Inline open curly braces! Next line) and caring about the final result without attention to what is running under the hood.