| ▲ | BrenBarn 8 days ago | |||||||||||||||||||||||||
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 7 days ago | parent [-] | |||||||||||||||||||||||||
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. | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||