8 ms·
Well, it's easy to complain. The reality is that money dictates decisions and behaviour; and if consumers wanted reliable stuff, they'd buy it. They don't. T
by wokwokwok 5y ago
Well, it's easy to complain.
The reality is that money dictates decisions and behaviour; and if consumers wanted reliable stuff, they'd buy it.
They don't.
They want free stuff, and if it doesn't work well, they'll complain and suck it up because it's free.
The idea that developers are somehow empowered to a) not do as they're told by their bosses, and b) should just go off on their own and do whatever the hell they want (eg. making things reliable), when it is not what they have been asked or instructed to do...
...well, it's a big ask.
If you want change you need to do one of probably these things:
- Empower developers to somehow write more reliable software at no additional effort.
- Convince consumers to buy more expensive stuff.
- Provide a legal mandate to punish companies that fail to adhere to specific levels of quality control.
- Provide a meta framework the punish individuals that fail to adhere to specific levels of quality control (eg. IEEE and other professional organisations which can expel you).
I can't imagine how you do the first two. Those are Hard Problems.
The last two have worked in the past in some circumstances in other professions... but, you know, many folk don't like the idea that there are codes of behaviour, ethics and conduct they should be forced to adhere to; but they want people to take personal responsibility for things not being perfect.
It's a bit of a joke that everyone has to 'do the right thing' with no rules to enforce it... but hey, it's easy to ask for, because you don't have to do anything except complain people aren't doing the right thing.
Thats why you can't have nice things like software that works.
- native_samples 5y agoIt seems much easier to find examples of the first two than the last two, really. I've been programming now for 30 years. Here are just ten of the major improvements the industry made to software reliability in that time, on its own, without government intervention of any kind: 1. Unit testing. 2. Garbage collection (no more use-after-free bugs). 3. Stronger type systems. 4. Then stronger type systems with usability close to that of dynamic type systems. 5. Widespread usage of encryption, signing and sandboxing (hacking being a subset of "stuff that makes software unreliable"). 6. Exceptions with useful stack traces, that in some cases can be caught allowing the program to proceed. For example, my IDE doesn't totally die if a plugin hits an assertion whilst analyzing code, it just means that plugin doesn't get to contribute to my editor session. 7. Tightly specified memory models like the JMM. 8. Excellent monitoring platforms. 9. State machine replication like Raft, allowing for entire datacenter outages to be made nearly invisible to end users. Result: Google servers are now more reliable than the internet itself. 10. Ultra-stable operating systems like Linux. In 1995 the most popular OS couldn't manage an uptime of more than ~45 days. Today you can hotpatch the kernel without a reboot. There are loads more like this. Software today is drastically more reliable than it once was. Meanwhile, what has the government done? I'm trying to think of some, but they've all been failures or actually made things worse. In the security realm, we can thank governments for things like FIPS cryptography, which is hardly relevant outside places where it's mandated because it takes so long to approve what are clearly upgrades. Governments can't even get reliable software out of their own contractors - they're in no position to lecture others on how to do it right when they can't even get their own house in order. But it's not enough to only consider what governments do for reliability. We must also consider what they do against it. There unfortunately the karmic balance is deeply in the red, because governments routinely stockpile exploits then lose control of them, undermine cryptographic standards and so on. They actually like software being unreliable because they see bugs as weapons. A big part of Google's Project Zero is about imposing software reliability against the will of governments.
- tchalla 5y ago"Show me the incentives and I will show you the outcome." ~ Charlie Munger
- DaiPlusPlus 5y ago> Provide a legal mandate to punish companies that fail to adhere to specific levels of quality control. This is the only workable solution - fortunately it fits right into established regulatory frameworks. ------------- Controversial opinion: I do think we need some kind of widely-recognized (i.e. not just in Texas) professional licensing system for SEs/SWEs to enable some kind of accountability for bad software products: ...When a building collapses and kills people, the civil engineer-of-record is accountable or serve as witness. Similarly when avionics software kills passengers (MCAS, etc) there should be a software-engineer-of-record to be held accountable or to serve as witness. Change my opinion. I know there's a big difference between safety-critical software systems and consumer-hostile inkjet printer cartridges ( https://news.ycombinator.com/item?id=28888214 https://news.ycombinator.com/item?id=28888214 ) - but more and more jurisdictions (especially outside the US) are going to call-out US and international software and hardware companies on their business-practices which means they'll probably institute something like this inevitably.
- consumer451 5y agoI agree with you. It is time. Code runs too much of our world to not have a formalized system of accountability. At least in some domains to start. One thing though, in the US, and in the case of a building, it would be a Structural Engineer not Civil. And specificity a PE, or Professional Engineer who has a personalized rubber stamp mark registered with the state. At least that’s what I recall from supporting a CAD department 25 years ago.
- Gigachad 5y agoThe difference is that construction is largely doing the exact same thing that has been refined over thousands of years and we know very well how it goes and have formulas to precalculate everything. So you can have a set of building codes which if you follow, are very likely to produce a perfectly fine building. While software development is completely making things up as you go because it hasn’t ever been done before. Any kind of government regulation would end up as a box checking exercise that wouldn’t add any more safety and probably introduce problems when products have nonsensical decisions added in to fit with some requirements.
- chrismorgan 5y ago> if consumers wanted reliable stuff, they'd buy it. Trouble is, often I can’t when I want to because no one’s making it—that the industry (whatever industry, you find this in many of them) has accepted mediocrity. For software specifically, my observation is that attempts to retrofit reliability, performance and the likes almost always fail: these are properties that you have to deliberately bake in with from the start, and maintain lest you find them difficult to claw back.
- spacemanmatt 5y ago> The idea that developers are somehow empowered to a) not do as they're told by their bosses, and b) should just go off on their own and do whatever the hell they want (eg. making things reliable), when it is not what they have been asked or instructed to do... > > ...well, it's a big ask. While back my brother's band had a song called, Money Goes to the Man. It captured this issue pretty well.
- lytefm 5y agoIn some industries where the consequences of failing software are fatal, e.g. medical devices or vehicles, 3. and 4. are in place and ensure that (usually) nothing bad happens. 2. isn't that important if everyone within an industry has to adhere to the same standards. For example, GDPR levels the playing field for any company that operates in Europe and ISO27001 etc for many industries. But sure, companies will usually do the minimum required effort - and that only if the threat of fines and audits is high enough.