[grishka]

> You had to take action to receive them.

What did that look like? Remember, back then, developers and users often had no after-sale communications at all. It was a technical impossibility more than anything. There was paper mail. There were telephone networks. That's about it.

I suppose you could occasionally call the developers of every software product you're using to ask if there is an update. I doubt anyone ever did that.

[BrenBarn]

> Remember, back then, developers and users often had no after-sale communications at all.

They often had no pre-sale communications either, indeed no communication of any kind. It was just like buying a spatula or a pair of shoes. You went to a retail outlet and bought the software; the developer wasn't involved in the transaction at all. It was just the consumer and the retailer.

Sometimes there was a postcard you could send to "register" your purchase with the developer, and they'd send you mail about new versions or the like, but many people never registered.

[godelski]

  > but many people never registered.

Which leads to things not getting patched, more bugs, and more computers getting hacked. A great system...

I'll also add that if it was a big enough bug that it'd end up on the news and that's how people got informed. Otherwise, like you suggest, good luck. But it was possible.

It is baffling to me that we are having this conversation on Hacker News of all places. Aren't we a community of programmers? How in the world does any programmer think for a hot second that code is bug free? Last I checked formally verifying your code was 1) very rare and 2) still impractical if not impossible for anything of sufficient complexity. Unless we're formally verifying our code, I absolutely guarantee it has bugs. I know we have big egos, but egos so big that we think we're omniscient?

[grishka]

> How in the world does any programmer think for a hot second that code is bug free?

If you stop bloating the scope of your product by endlessly adding features no one ever asked for, you'll eventually run out of bugs.

Also, while it does not make you "omniscient", working with a known stack instead of following fashion does help a great deal with preventing bugs.

[pabs3]

The problem is that the scope changes based on circumstances outside your control.

[godelski]

I agree that not expanding scope makes things easier but it doesn't solve the problem.

I also agree that knowing the stack goes a long way, but again, doesn't go all the way.

Omniscience is required, by definition. Even if just omniscience about the software you are building. MEANING you know not just all your lines, but all the lines of all the dependencies, the compiler, and the system it is operating on. I have yet to meet anyone that comes anywhere near approaching this knowledge, including many gray beards.

It is utterly foolish to proclaim your code as "bug free". Since you don't seem to be aware of sayings like "software rot" allow me to introduce to you to another one

  There's two types of programs:
  1) Those with bugs
  2) Those that nobody uses

In case it isn't obvious, the joke implies that all programs have bugs, it is just that developers are less likely to be aware of them when few people use them. This is, of course, because there are too many variables for any developer to account for, even in simple programs.

[BrenBarn]

I won't deny that all software is going to have bugs. But I think there has been a real shift in mindset over time. When it was harder to patch and, there was greater incentive to make each release a well-tested, coherent product that offered clear advantages over the last one. As it's become easier to patch, it's become more tempting to make each release just a sort of snapshot of what's more or less ready at a certain time, or alternatively a tiny increment. In other words, users are now the testers.

I'm not saying things were perfect in the era of physical-media software. I'm just saying there were some good practices that were made necessary by the constraints of that era that still can be beneficial today, even though we don't have those same constraints.

[godelski]

  > But I think there has been a real shift in mindset over time.

With this I'm in full agreement. We've moved even further now to where we're selling products that do not yet even exist. It was bad enough we were selling stuff that wasn't fully tested, but worse that we're selling things on a promise.

I'd even go so far as to say that the selling of hype creates an environment where we almost certainly will have worse products. The business people are most interested in the sale, not maintaining the customer. The incentives to fix things or bring them out of alpha or beta release disappears. Even if this is harmful to the longevity of the company. But that doesn't matter either if you're only thinking one quarter at a time...

The point was never that it is easier to patch now and back then it wasn't possible. The point of this conversation was that we can't begin to solve the actual problems if we can't recognize why they happened in the first place. To base our premise on products being finished in the past will only lead to us cycling back to where we are. Someone just has to come up with the /brilliant idea/ of "what if instead of mailing patches, we send them over the internet!" It is good intentioned and will result in more users getting patches. We should not throw out the baby with the bathwater!

But the abuse of the environment is an entirely different problem. You're right that the ease of shipping patches lubricates this abuse of shipping to prod to early. But it isn't a causal variable. The causality here is the business people being uncaring about the quality of the product. The causality here is engineers not taking enough pride in their work to push back against the business people. The causality is that we've structured our work environment to reinforce this behavior and promote those who fall in line instead of those who do quality work. (quantity over quality) The causality here is that customers cannot differentiate a well designed product from a half baked idea and a promise. The causality here is that we call product vision a product demo (demonstrating what we want the product to be, not what the product is).

There's more causal variables, but these are clearly part of the chain of problems. The problem is that the situation is complex! But we can't fix complex problems by oversimplification and denial of their complexity. We have to break them down into simpler parts and address those smaller and more manageable problems. I mean we use this same procedure every day to write code and do numerous complex tasks!

But we can't solve complex problems if we deny the existence of their complexity.

[BrenBarn]

I basically agree, but I would say that that "lubricating" effect is still causal. I mean if something is stuck and lubricant is added and then it starts to move, well, the lubricant was at least one of the causes of its moving.

It's true that the major factor is the ideological shift away from caring about doing a good job. I'm not sure how to address that though.

[godelski]

A lubricant doesn't cause something to move, but it makes the movement easier. It doesn't apply the force, even if it reduces the force required to create the movement.

Causality is the force, not the modifiers.

Think about it this way:

  Lubricant exists, force doesn't =/=> movement

  Lubricant doesn't exist, force does => movement

We can make things less likely to move by removing the lubricants but we can add as much lubricant as we want and it won't start making things move.

This is why I say "don't throw the baby out with the bath water" because we actually still want the baby. But we do want to address the root issues.

  > that *the* major factor

I want to be clear, there is not a singular factor.

Normally we solve problems by breaking them down into little ones. But the harder version is finding what little ones result in the big one. It's like working from the top of a graph to find a node and it's children vs starting at a leaf.

  > I'm not sure how to address that though.

Start with the little things. Start where you can. If you have the chance to make something better or hold someone to higher standards, try that. If you see someone else trying to, lend them a hand. Often we don't stick or necks out because we're afraid we're alone. But we're not. The "first follower" is one of the most important people in creating a group. They're a lubricant ;) You don't have to be first or take the most risks, but if you can make it easier for people to do so then that's still very helpful