* you get paid a lot less
* the companies and industries move very slowly
* you spend a lot more time writing long-form, some time just re-using existing stuff wholesale, and almost no time building actually new things
I mean like Real Engineering fields. What we do in software is not real engineering, not even close. That has pros and cons.
I saw someone else talking about Rust, but I don't think that's what would happen in such a world. Rust is too new, if the company was actually liable for problems, the legal arm of the company wouldn't let you use it. I think what would happen is that everything would slow way down, half or more of the people working on code right now would lose their jobs, hobby programming would either disappear or become very insular and not well-distributed (because if companies are liable, then individual people will also get sued for bad software), and you'd spend most of your time working with small pieces of 30-40 year old technology.
I think that eventually, software may get to such a point. Just, be careful what you wish for.
I believe lightweight formal methods are quite promising and might let software move relatively quickly and economically while retaining some rigor. Look into Liquid Haskell for some ideas that might become mainstream.
I imagine a whole bunch of power could be derived from this in Haskell. I don't know how heavily contracts were/are used in Eiffel (I don't think it's so popular these days).
It would be great to know if contracts had a measurably useful outcome on projects and what that measurable was (addressed a market that we otherwise wouldn't have been able to, dropped runtime errors to only system based errors, etc).
WRT your projects, I imagine it would be great to see your product out there working with a known level of uptime and quality. I could imagine it's a bit of a shift from the normal "throw it together" of ... a lot of software.
I'd be curious to know what it's like to work on day to day, year to year. I imagine lots of software will still be "throw it together" for a long time yet, but even if the subsystems are formally verified, it could have a useful impact on the software that consumes these (verified) modules.
As for my day to day job, I think the real difference with common software development was that requirements were very well understood right from the beginning. This allowed us to formalize them into axioms and then derive the implementation in a stepwise fashion using some Standard ML tooling.
I've also worked on proving theorems on existing software artifacts, but that's way harder both in terms of effort and number of defects.
That assumption is deeply flawed. We do not hold toy car manufacturers to the same standards as actual car manufacturers. We do not hold every manufacturer of screws to the same standards as the manufacturers of screws on airplanes. Or rather, we do hold them to the same standards, just we know that certain use cases basically can not cause too much harm in the event of failure and thus in practice the standards needed to mitigate the worst case are much lower.
Software liability does not mean that everybody suddenly needs to take the same care as safety-critical industries. It only means that if you are making safety-critical software and you are incapable of separating the safety of the critical components from the non-critical components. What it really means is the repudiation of the one-size-fits-all lowest common denominator expectation of quality.
I worked at a place that had a formally verified application running on some mainframe. It was wonderful, except that the process was excruciating and maintaining that validation prevented any changes. Every code change cost a minimum of $25,000 2002 dollars.
It was dumb. They would have been better off with a paper process and army of clerks.
As for the rest of the open source ecosystem that goes into Linux (the operating system), it would probably be abandoned.
NotPetya which took down Maersk and did $300Mn of damages was apparently spread (through their Windows AD) by compromised admin accounts which they were lax at managing[1] rather than kernel exploits. The SolarWinds Orion security flaws were blamed on weak passwords, not OS kernel exploits. And if getting inside, something like last month's SystemD/polkit exploit[2] shows that attacking the kernel isn't always necessary for privilege escalation.
Linux the kernel is important but it's the heart inside the ribcage, not the first or last line of defense, or the main thing to target.
[1] https://gvnshtn.com/maersk-me-notpetya/
[2] https://github.blog/2021-06-10-privilege-escalation-polkit-r...
I imagine it would depend heavily on how large the liability was. I expect individual components would begin being replaced with "certified" commercial alternatives. If not existing ones, definitely new ones. Remember that they make money by selling to customers who would also be subject to the same rules. Look at healthcare, aviation, and finance for concrete examples of the effects (both negative and positive) that red tape has on software and IT policies.
There's an entire FOSS ecosystem and the vast majority of it is composed of small-ish slow moving projects. The tech industry is also an entire ecosystem full of small and medium sized players. Even if behemoths such as mainline Linux and AWS somehow survived unchanged I would expect a much greater chilling effect on smaller players that couldn't afford to take on such risks. New companies and software projects would become very difficult to get off the ground (healthcare is a good example here). With few to no new entrants forward progress would slow to an absolute crawl.
All of this has downstream effects. Fewer consumer devices running Linux would mean even less hardware support. Security related liabilities would almost certainly mean more vendor locked hardware. Would companies like Purism remain viable (or even legal)? The steady stream of new FOSS users and contributors would almost certainly dwindle.
Depending on how such regulation was written, could open source contributors themselves become liable for a freely provided product?
And then the US would be forced to decide whether to accept imports of foreign devices and software (created under the no-liability framework) or to stay with homegrown technology frozen in time.
The best thing you can say about this proposed reform is that it would make a great plot for a sci-fi novel.
I mean the hub thing and synergistic collaboration are cool but employees are not 3x more productive because of it.
Why would it be frozen in time?
Local development would rendered unable to compete with the fast moving zero-liability model that quickly and cheaply delivered the features that consumers wanted. Either it's import would be banned or the local industry would crumble.
> you get paid a lot less
Isn't that the point? That is, the argument is right now the money goes to the devs, management, and stockholders, when it rightfully should go to those people damaged by the software (or toward preventing them from being damaged).
> the companies and industries move very slowly
How much of this is due to liability law and how much is due to natural aspects of the relevant technology? Liability law may be part of the reason, but software probably naturally moves faster than other engineering fields.
If the money is supposed to go towards people preventing damage, wouldn't that include devs?
> How much of this is due to liability law and how much is due to natural aspects of the relevant technology?
I can only speak from my own experience in biotech, but moving slowly was due to a lot of compliance box-ticking that didn't actually contribute a lot to either safety, reducing defect rate or meeting requirements. Conway's law applied: since bio engineers and lab techs move slowly, so did the software org.
> * the companies and industries move very slowly
The reason the rest of us move so fast is we skip safety, security, quality, and maintainability to get to market. Those things are usually perceived "not bringing immediate customer value".
And deliver cheaper results.
The only reason our processes and practices aren't much heavier is because the stakes are lower. People do not die if a Tweet doesn't make it through, but they do if a bridge collapses through.
The threat model is also significantly different. If we go back to the bridge analogy, a company like Microsoft has to deal with tens of thousands of people trying to blow it up or find some weakness every day, while a million people are going over it. Just by sheer laws of scale they are going to have a tougher time, Real Engineering or not.
True, and what you're saying is generally true. But what were the total consequences of the Equifax breach? We can't even quantify it. Snowden himself in the article mentions activists and journalists being killed because of these vulnerabilities. There are definitely counterexamples.
"Real Engineering" has definition and it fits SE, doesn't it?
Computer industry iterated and managed to reach the point where we can move really fast and do not break computers with bad code. That's result of thousands of hours of engineering effort of previous generations.
>Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tunnels, roads, vehicles, and buildings. The discipline of engineering encompasses a broad range of more specialized fields of engineering, each with a more specific emphasis on particular areas of applied mathematics, applied science, and types of application. See glossary of engineering.
I agree.
Let's not use tools as a crutch. Roman engineers built bridges that are still standing today with little to no maintenance. There's no indication that those structures are going to fail anytime soon either. I think we can agree that their tooling was worse than our current bridge building tools.
> I mean like Real Engineering fields. What we do in software is not real engineering, not even close. That has pros and cons.
So the word engineer is probably loaded if not dated, a throwback to engineering's boom in the 19th and early 20th century. No idea why we still use it since software is more like math than anything else. Computer scientist just never stuck.
Roman engineers didn't understand the principles of civil engineering; I'm sure they built a lot of stuff that fell down (survivorship bias). So they started massively over-engineering their structures ("moar rocks!")
Survivorship bias is the favourite catchphrase for HN these last few years.
I think you overestimate the importance of academic theory over practicality.
"Moar rocks" is a perfectly reasonable way ro fortify a structure. Because 1000 years from now engineers will be wondering how any of our stuff survived ("moar cement and steel rods!")
So yeah, I have a healthy respect for practicality.
That's the funny thing. As a software engineer, if I have to build something that might kill someone, I just don't do it. But so-called "real engineers"? Bam, condo building down, people dead. Bridge down, people dead. Tacoma Narrows? Experimenting on people.
If "real engineers" were half as good at their job as I am at mine, we'd have a space elevator and people would be going up and down it every hour and the only problem they'd face is that the music is sometimes not that great. But they're too busy killing people to create $10 in value. I'm too busy not killing people and creating $1 million in value. The numbers don't lie, dude. The numbers don't lie. More value made. Fewer dead people.
People don't like to hear it because of the fetishization of this "Real Engineering" nonsense. But it's true. Software engineering's generational scandals are outdone by a "real engineering" project every day.
Maybe we should teach them ethics, because whatever class they took on that, it didn't take. As a practitioner of quality and making money with zero killing, I could help.
You're trying too hard. It's embarrassing.
Apply strict liability to software, and you'll see the same results. Every piece of software will have to be constructed with the care of a medical device. Expect most forms of technological progress to come to a halt. Some part of the HN crowd will post "I want that" from their iphone (which wouldn't exist under such a regulatory scheme).
There’s one story about a hip implant that went bad. Turns out the doctor recommending and performing the surgery was also the patent holder and had a vested interest in getting this particular implant in as many patients as possible. Turns out the patient was actually patient #8 who received this particular implant. Also the implant wasn’t fully approved yet and the FDA simply trusted the doctor to monitor the device for problems.
Also this isn’t isolated. The chapter has several examples of medical devices going into patients and patients experience negative health outcomes. Turns out laws are only as good as the agencies that enforce them.
If a company makes a bad implant, it's very visible, but all the potentially improved hip implants that never get built because of the barrier these laws create are invisible.
The point is there should be a better way that just pull the plug on anything potentially unsafe.
And then I can sue them to death or make a report to health authorities that will act accordingly.
In 2000, the average age of the nation's 150,000 single-engine fleet was more than 30 years. By 2020, the average age could approach 50 years
https://www.faa.gov/aircraft/air_cert/design_approvals/small...
Notice that "accident" definition conveniently excludes tons of partial failures! (see the legalese of 49 CFR § 830.2 - Definitions.)
To make parallel with broader discussion, the security failing of software could be considered "partial failures"...
There's a lot of legitimate criticisms about modern OS security, whether we're talking about Linux/Android, MacOS/IOS, or Windows. However, we can't ignore the scope of these programs. Supposedly Windows 10 is approximately 50 million lines of code and due to its overwhelming popularity it has almost certainly been targeted more often than all of the other OS's listed combined. I am pretty sure all of these operating systems are > 10 million lines of code.
Whose work are you going to rely on instead? The level of security in these OS's isn't equal across the board, but I assure you zero days exist for all of them and barring some kind of miraculous technological breakthrough, they'll continue to pop-up from time to time as long as they exist.
Suppose someone pulled off a miracle by making a security-focused OS that's easy for non-technical people to install and use and actually gains enough traction to establish a market share. If such a thing existed it would likely get lots of things right where others have failed, but they would also likely get lots of things wrong. It doesn't mean we shouldn't try and it doesn't mean we shouldn't encourage both old and new companies to try and improve the situation, it just means that its an incredibly difficult and likely never-ending task. Security is a process, not an achievement.
Probably not and they should try to reduce the size if it makes sense. However, if all of the OS's I listed are above 10 million lines even in the best case scenario a modern operating system isn't going to be anything less than an overwhelmingly large and complex program.
While i don't disagree with the point you're making entirely, I have made many mistakes in my career and i still get hired and i suspect you have too. Most people make mistakes, and still have jobs.
Realistically, people/orgs make mistakes. Requirements change. Expectations change, security practices change, etc.
Roman bridge engineers would likely struggle to build bridges at the scale and requirements they're built to in 2021 (miles long, tall, huge train weights, etc). Things change in technology jobs a LOT faster than typical NSPE engineering licensees' jobs. Its a different world. There are probably bridges under contruction today that were designed before the iphone.
Say goodbye to open source software!
Easy to say; not so easy to do. It is actually difficult to answer the [seemingly] simple question “What, exactly, is ‘Quality’?”.
I think I do a fairly good job, there, on my own work, but what works for me, won’t work for most.
Who even stands a chance? Colin Percival - math prodigy, cryptographer, former FreeBSD security officer - has paid out thousands in bounties for over two hundred bugs in Tarsnap software (not all security flaws) including buffer overflows, divide by zero, double-frees, mistakes in error handling, Unicode string handling error, numeric overflow mistakes, padding errors, user input handling bugs and one "critical security flaw" (against his very high standards) - https://www.tarsnap.com/bounty-winners.html
If someone like that working full time on a very constrained single purpose product can't make flawless software, what sense does it make for you to sneer at Microsoft as if Windows is singularly flawed here?
> "If Microsoft products are so infallible when used as instructed by Microsoft, then why would Microsoft have a heart attack as Snowden suggests."
They aren't, they're Swiss-cheese. So is approximately every other general purpose computing product, software and hardware, with the possible exception of a handful of very small very specific battle-hardened tools. Even the non-general-purpose walled garden appstore devices are Swiss-cheeses.
Possibly their heart attack would be because they are one of the biggest software development companies on the planet with a huge range of products used in tons of companies, so such a regulation would disproportionately affect them more than most companies? "All" Facebook develop is a web page, and very few companies use Facebook or Instagram or Oculus except by sending money and adverts to Facebook. Microsoft would have to secure a ton of large-scale software used on company premises in environments they have no say in. Seems to me the result of such a ruling would be something like Microsoft stopping selling on-premises software entirely and offering only web access to hosted Outlook, Office365, SharePoint, SQL, Biztools, Dynamics, with a ton of extra checks slowing them down, and companies faced with either using Microsoft online tools where Microsoft is responsible for the security or choosing on-premises tools like LibreOffice and Thunderbird and FireFox where they have to take responsibility, their legal and insurance would push them to Microsoft world with even less configurability or interconnectivity than there is now. It may be more secure, it doesn't sound great.
> "Instead we frequently see discussion blaming users of the software, i.e., Microsoft's customers, or even suggestions to make the customer liable, or comments from "security experts" on how Microsoft has made such amazing strides in securing Windows (a tangent)."
Not a tangent; Look at the recent discussion on HN about Windows Defender, and pretty much any security choice - it's full of people bemoaning Microsoft making decisions that are mildly inconvenient on the grounds of "how dare they think they know better than me", "I demand to be able to turn these security features off", "I want control to be able to do anything". If Adobe Reader is vulnerable and lets someone ransomware all your documents, what benefit is it to you if Windows underneath is an impregnable fortress? If someone can steal a user's 2-factor auth backup code from their house and access their remote VPN and exfiltrate data, what good is a perfect OS underneath doing for anyone?
This isn't whataboutism ("others are insecure so why can't Microsoft be"), and although it is somewhat in defense of Microsoft it's not "waah leave Microsoft alone", it's ... what kind of world are you living in where you heavily imply that Microsoft could have done differently and didn't? Microsoft trying to write Windows 3.1 in Pascal or ADA would have had their lunch eaten by every other company which didn't.
> "What a remarkable state of affairs we have today where employers such as Microsoft can call their employees "engineers", and yet both the employer and employees are absconded from any liability for the so-called engineer's work."
You think changing their job titles to "programmer" would improve the situation?
I think it's somewhat reasonable to complain about the approach taken to security in Windows. MS had a lot of work to do to stay on top as long as they did, but they were also extremely well resourced and dominant for a significant time, where they could have made bigger systemic changes to prevent swiss cheese getting released in the first place. They could've built their own rust-like language, maybe, built some great static analysis & fuzzing tools, or generally advanced their own internal exploit discovery to beat outsiders to the punch. That we've mostly settled for constant security updates upon exploit discovery in the wild and blindly assuming super old code is safe (until it isn't) seems like a failure to act (a failure of incentives?) and not a necessity.
They tried. Windows Longhorn was to be "entirely" managed code in the early 2000s, by 2004 they walked that back because vendors didn't want to rewrite their software for managed code and there were too many performance issues. Then they scrapped Longhorn altogether. As a research project they built: "Midori is an operating system that did not use Windows or Linux. Was written in C#. Took 7 years to build and included device drivers, web servers, libraries, compilers and garbage collection.". From what I know, they tried harder than Apple+macOS or anyone+Linux kernel and couldn't do it. To then casually say "they could've" is not so convincing. Especially if in this "you're responsible for bugs" world they would have had to have Proto-Rust production ready around the time of Windows NT in 1993 or so.
https://www.theregister.com/2005/05/26/dotnet_longhorn/
https://www.theregister.com/2004/05/06/microsoft_managed_cod...
https://www.infoq.com/presentations/csharp-systems-programmi...
https://news.ycombinator.com/item?id=27809296
> "That we've mostly settled for constant security updates upon exploit discovery in the wild and blindly assuming super old code is safe (until it isn't) seems like a failure to act (a failure of incentives?) and not a necessity."
The blogpost I link below[1] was written in 2004, and he says "I truly believe that the patching fad in which we are currently living is not going to last much longer. It can't. In another couple years, we'll have one full-time patcher to each system administrator. What's odd is that if companies simply exercised a bit of discipline, it wouldn't be necessary at all. Back in 1996 a buddy of mine and I set up a web server for a high-traffic significant target. It was not the Whitehouse; it was a porn site. We invested 8 hours (of our customer's money) writing a small web server daemon that knew how to serve up files, cache them, and virtualize filenames behind hashes. It ran chrooted on a version of UNIX that was very minimized and had code hacked right into the IP stack to toss traffic that was not TCP aimed at port 80. 10 years later, it's still working, has never been hacked, and has never been patched. If you compute the Return On Investment (Or ROI in the language of Prince Ciao) it's gigantic."
And yet the patching fad has got hugely worse since then, and all the factors he complains about - CEOs buying from salespeople, desire for customisability and flashiness - are all still driving the industry hard.
[1] http://www.ranum.com/security/computer_security/editorials/m...
Even when I say "they could've", it was in some part wishful thinking that we can even get to a state of the art where constant bug-patching can go away. I believe we can in theory. I also know that the nuance of reality often gets in the way of that kind of idealism.
That sort of discussion is quickly dismissed on HN. And probably elsewhere on the web/over the internet.
Instead we frequently see discussion blaming users of the software, i.e., Microsoft's customers, or even suggestions to make the customer liable, or comments from "security experts" on how Microsoft has made such amazing strides in securing Windows (a tangent). In the real world, outside the Redmond/Silicon Valley monopoly space, how many mistakes does someone have to make before we start to suspect there might be problems with relying on that person's work. Even more, how many times do we hire someone knowing they have made 500+ mistakes in prior work leading up to their application.
If Microsoft products are so infallible when used as instructed by Microsoft, then why would Microsoft have a heart attack as Snowden suggests. What a remarkable state of affairs we have today where employers such as Microsoft can call their employees "engineers", and yet both the employer and employees are absconded from any liability for the so-called engineer's work. The number of "second chances" Microsoft gets is nothing short of astounding. A bit like the number of pardons we allow to Google or Facebook for privacy infractions. Infinite.
https://www.nspe.org/resources/professional-liability/liabil...