3 ms·
I think you misunderstand quality versus competition. The purpose of regulation is to impose a minimum baseline of quality. Software does not have regulation.
by austin-cheney 16d ago
I think you misunderstand quality versus competition. The purpose of regulation is to impose a minimum baseline of quality.
Software does not have regulation. In many areas of software we force shit quality on the users and just expect them to take it without complaint as a common practice. Then we as developers, like entitled children, completely rage the moment anyone casts light on this insanity.
- eru 15d ago> The purpose of regulation is to impose a minimum baseline of quality. Quality has more than one dimension. Food regulation is mostly concerned with "don't poison the customer". It doesn't otherwise care about things like taste or smell or texture.
- carlosjobim 16d agoIt's because something is better than nothing when it comes to software. Which people always forget. Is eating spoiled food which gives you a disease better than not eating anything? No, it's worse, and therefore the minimum quality regulations make sense. Is having low quality software better than not having any software? Yes, in almost all cases it is better. So a minimum quality regulation doesn't make sense. When people put quality requirements too high on software, we get situations where for example public transport information and tickets aren't available digitally because the government is taking 15 or more years to make the "perfect" platform. The public is better served by a shitty solution the first years, an OK solution after that, and hopefully a good solution later on. Delivering fast has a very important value when it comes to software, because you can replace it with improved versions at no physical cost. Delivering a vehicle which will kill you or food which will make you sick is very different. In those cases nothing is better than anything.
- austin-cheney 16d ago> When people put quality requirements too high on software, we get situations where This is a common trope of the unregulated: We can’t raise quality because we can barely deliver as it is. The real message there is that the user should suffer so that you won’t.
- carlosjobim 16d agoI'm a consumer of software, not a developer. And I can tell you that as a consumer I always prefer something over nothing. If you can do it better, you have a golden opportunity, which you should take, to deliver something better to the market. Otherwise, you haven't much reason to complain that other people are doing at least something.
- emn13 14d agoThe thing is, it's a false dichotomy. Raising the quality bar makes software a lot _easier_ to deliver, in practice. Even for a not techie, the reason is probably somewhat intuitive - if you're trying to add features to something that's a hugely complicated mess, you're going to struggle and cause many bugs; but if your process allows for the creation of high quality code, you have the means to do so with confidence, and that usually means quickly and reliably. The real issue is one of timing and tech debt - higher quality software is cheaper and better, but... that's only over time. If you want that new software from scratch _now_, and don't have the time to set up a high quality development process, you can hack something together quickly. If the software is small enough, the person or LLM writing it smart enough, and while everything from requirements to code is still fresh in memory - that works pretty well! But that process scales poorly, and yet it's what we've as an industry done far too often, and at far too pervasive a scale. So even though we know and have examples of how to design software better and more cheaply, actually getting to that situation isn't a simple question of trying harder; it's working entirely differently. And unfortunately, we build more and more of our software on the building blocks of the past, and many of those are themselves of low quality too; the more we do that, the more entrenched low quality becomes. As an end user that kind of isn't perceivable; it just means all software is a bit worse and more expensive, but as humanity, it's absurd how much effort we waste working around fairly trivial mistakes made in the past, typically by organizations that just had no incentives to care about future impacts especially on others. While I get the instinct to prefer something over nothing as an end user it kind of is exactly that bad habit that got us into the mess we're in today. We don't build and throw away; we copy and tweak - so all the messes are inherited, kind of like a form of pollution.