The Software Industry Is Still the Problem

In Quebec/Canada there is this huge company called Trigone. They build all kind of big buildings here and their modus operandi was to create shell companies around Trigone. So the shell company would build the building and instantly bankrupt after. The people who bought part of the new building were stuck with all kind of problems and no way to fight back.

The RBQ which is the agency in charge of making sure the rules are respected for construction, removed all their licenses yesterday.

It took years, but finally people will no longer suffer from crooked builders.

Here is the news. It's in french. https://ici.radio-canada.ca/nouvelle/1828502/construction-re...

I wish there was some kind of agency in charge of penalizing crooked software companies which are known for years to screw businesses. It will take time, but we will get there.

Other engineering sectors do have this kind of liability. What do these sectors have as well? Standards. If a house needs to be built, there are _loads_ of safety regulations to follow. Standards to adhere to. Inspections to be had. Only then is someone allowed to move in.

Software? Decisions are often made without either knowledge or a plan. Agile is a thing. Deadlines are shorter than ever. Also: ideally it needs to be for free. Just pick up that package from Github, it should be good enough (maybe it even has Tests, but who cares, really).

The software projects that are heavily regulated? Take forever to plan and complete. Massive budgets. And still usually are not able to manage to be bug free.

Also: software is really, really complex. And: it is easy to attack. Let's be real: other engineering projects are really easy to break as well - some well placed C4 usually does the trick. But it is hard to get C4. Hard to get access. Also, hopefully, there's an ethical barrier to doing it. Software on the other hand? From home. And once there is an angle of attack, it can attack millions of targets at once. And there are no visible victims, at least not right away, so the ethical barrier is lower as well.

Ok I'm rambling. Anyway. This, as is software, is a complex issue. And liability could totally be a thing, but that means an end to ad-financed applications or 2$/user/month services. You get what you pay for (well, sometimes not even then, but you definitely do not get anything for cheap any more). Perfect example: super-cheap IoT devices from China. Well engineered ones doing basically the same thing? 10x, sometimes 100x the price.

Software is buggier than buildings because it is built on human made abstractions all the way down. You can reason about a structure if you know where the buck stops (Newtonian physics basically). Computer software isn’t that.

> As I write this on an early July morning, 200-plus corporations, including many retail chains, have inoperative IT because extortionists found a hole in some niche, third-party software product most of us have never heard of.

As I write this, millions of cars have gotten stolen due to vulnerable lock mechanism. A thief can with simple toools just open the door, start the car and drive away. Do we sue the engineer designing the lock for billions in damages? No. It isn't reasonable to blame engineers for everything.

> It may be less obvious why the state cares who runs pet shops, inseminates cattle, or performs zoological taxidermy, but if you read the applicable laws, you'll learn that animal welfare and protection of endangered species have many and obscure corner cases.

But how did many those laws come to be?

Is it because the state cares about these professions a-priori, or because established players in those industries lobbied to restrict who can enter the profession in order to protect their market position and comparative advantage?

And yes, the latter can be true while also it leading to an outcome that produces higher quality than if thise laws were not there - but quality may not have been the reason the laws were proposed in the firt place.

On what basis should a developer be held liable for damage caused by software? Certainly a group of 'experts' could identify outright negligence.

But in engineering professions, the standards are well understood, and measurable. Software is not the same at all.

The whole argument appears spurious, and the arguer, sanctimonious.

When it comes down to it, most software bugs don't matter. Reimburse the customer, wait a few days for a dev to fix something, whatever, it'll get resolved and everyone will be whole again. Contrast this with construction, if there's a "bug" in the building, people can die, or lose housing, or companies can lose large amounts of money. Bug in a billing system? Just try and pay again next week.

In industries where software bugs do have large consequences, well they tend to be heavily regulated industries already: finance, aerospace, government systems, automated cars, elevators, medical devices.

The other types of engineering the author refers to that are subject to certification involve the physical safety of other people.

But still, plenty of software development roles are subject to professional liability, particularly where the work is linked to people’s physical safety. As a contractor or director of a company providing software services, I’ve been required to have professional indemnity and public liability insurance, and part of that involves verification that I’m sufficiently educated and experienced to be competent enough to mitigate the risk.

It doesn’t make sense for there to be industry-wide liability standards, as roles and risks vary so much, and certification comes at a huge cost. It’s absurd that the same standards of liability would apply to an aviation software job vs the part time IT guy at said sub-20-person office whose responsibilities are limited to setting up MS ActiveDirectory and keeping the printers running.

This is a rant about a non-problem.

That's okay, no one will be able to afford software any more afterwards.

I suppose the likes of MS could get away with selling a bug free operating system for only 100k/seat. All the other cheap apps with less than millions of customers will simply vanish.

Banks and financial entities are the ones that have the hardest government regulations, including how they write software. Regulating software engineers would just make the rest of the industry look more like those, I wouldn't call that an improvement. The problem is that we currently don't know how to properly regulate software engineering to get good results. Regulations doesn't even seem to protect against vulnerabilities, so why even bother until we understand better how to regulate it?

Oh look. An institution who’d be the first to sell certifications wants to make certifications mandatory. Nah, thanks. At least I’m Software one can still innovate without having to cut through miles of red tape.

The customer is paying for it either way. Do you want liability insurance on your critical software project? Sure! But it'll just balloon the already ridiculous costs and a fraction of that money will maybe be spent on educating the engineers and ensuring the system is secure.

On an individual level, expect to see this: "Our records indicate that you have previously committed (a minor, unrelated change) to a software repository that was later exploited, unfortunately we are not able to offer you a position at this time (due to insurance reasons)"

I think rather than broadly comparing software engineering to other engineering professions in general, it would be more apt to compare it to plumbing specifically. Building bridges, planning houses and roads, etc often comes with strings attached because lives are at stake. Focusing on this distinction and then dismissing the argument as it's not applicable to software short of a few specific areas is easy, but missing the forest for the trees. Plumbing is a better comparison. Most of the time, there's no life-threatening danger involved (although there are exceptions). In general though, failures are simply both very unpleasant and get expensive fast. If you need to replace an old tap you may be able to do get it done on the cheap or even do it yourself, but if you want to run water for a whole building, you will most certainly want someone who comes with certifications, liability insurance, etc. In the long run, as a society we would benefit greatly from introducing varying kinds and levels of certification in the software industry, and for similar reasons. Like plumbing, there's no problem if you do smaller things around your own house. But if you want to build software that sits at the heart of say nationally important systems you should be tested before you're let at the wheel.

So that would mean I could f.e. Sue Microsoft if they push an update that breaks my whole network?

... I like this idea

It is a great idea, but this is not going to work. The difference between construction and software engineering is the number of active users. If damage is made and people sue, your liability is limited by 1-10000 building occupants and visitors. No insurance company will take the risk of paying to 1M-1B active users of software.

And of course there is also a problem of implementation. Even with deadline in 10 years industry will not be able to certify majority of the engineers or develop an engineering process where licensed engineer in USA or EU can take responsibility for the code written by 10 engineers from another country with different standards (they can even be licensed, but those licenses won’t be recognized abroad).

> "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization."

Except that isn’t what software engineers largely do, we aren’t building the nth copy of the same building with a slightly different skin. Those kind of largely canned projects are straightforward and mostly offshored to low cost countries.

The other type of project is complex and unpredictable because no one knows the full scope of the project, the specifications and interactions. Most of the complexity and time in software engineering is getting that sorted, not the coding. Not to say coding something complex and non-trivial is easy, but the main challenges aren’t the code IMHO

Liability implies lawyers.

Contracts also imply lawyers.

What if we put the liability requirements into the contract, and see how it goes?

Might we discover that legal language is just another programming language as fraught with peril as the software?

Don't take my word for it: make that legalese happen.

A small internal software group like mine would almost certainly be a casualty of any real increase in software liability.

On the other hand, the inevitable slowing of technology change and consolidation of libraries, languages, and frameworks would be kinda nice. Hard won, deep knowledge of technology that is 20 years old would be worthwhile. And I could finally stop yelling at JavaScript frameworks to get off my lawn.

I view software as a form of literacy as opposed to engineering. Silicon chips - that's engineering. Codifying the process used by a large corporation to tell all its other systems a new joiner has arrived called "bob smith". That's writing something that other humans can read and can be executed by these engineered robots we have.

While my heart is socialist, my head is market-driven. And I think a market solution is the best option here.

But markets only work with informed buyers.

If my literacy idea is right - then no-one can judge software without being software literate (and having access to the source.) Just imagine a world where people had to buy the best books - but that the literacy rate was under 1%. We would have podcasts on that great book, the CEO would sign off on a purchase after and .... - books would be like software is here. Success based on marketing and yes minimising liability (no one ever got fired for buying microsoft). Linux would be samizisat!

I vastly admire Poul's incredible contributions to FOSS - but software liability is best fixed in contracts (where it usually is).

Edit: The only sane way (#) to build liable software is with some form of proof-based modelling - and this is even after decades of research horribly limited and does not reach into areas we wrote or use most software.

I am afraid software is just an extension of the human technology of speech and writing. It is a way to express ourselves in symbolic form outside our brains. It is probably the second most important development in human history - and we need to adapt all of society to be able to harness its benefits without too much harm. The crap IT surrounding us now is the pollution of the first coal driven factories. We will get better - our problem is to do it faster.

On a different note, most software (hence most bad software) is written in house - so the software that makes a bank a bank or a construction company construct, that is mostly already covered by liability. Your bank sends the wrong amount to the wrong bank account? That's been a liability since before the USA was a thing, and so the onus is on the bank to ensure it writes the software correctly. The fact that this is insanely hard implies to me that we need not just "better training for software developers", but "redesign our entire organisations" and probably our whole societies (let's start here: most things written down are done so openly - published or emailed or sent around. Most software code is closed and "proprietary". Change that first)

(#) I can imagine many companies taking on software liability without caring about the risks - but they don't sound like the people I want building airplanes, power stations etc etc.

What is the equivalent of open source software in the physical engineering world that this author respects so much? How is it regulated?

If there isn’t such an example, then perhaps software is a category of its own and thus its problems can’t be solved by legacy regulatory tooling.

Licensing computer engineer and scientist - I was wondering when this idea would surface. I mean, that is a great way to strengthen monopolies and consolidate existing players. I didn't expect such a suggestion would come from a Freebsd core developer.

Licensing is about compliance. It helps better control who has access to a certain set of skills, and who can make a living off such skills.

License could require you to be certified for certain technologies, which mean whoever has the best lobbying power win (Hint, it's not Freebsd). It's a great way to keep market shares for specific interests. Not sure how this is good for the industry.

Licensing means you can put barriers to entry for specific demographics (ineligible if born in a specific country...)

Licensing means you can create an entire business model just around licensing fees and licensing bodies, which usually mean some people are left off the game.

You want to increase professional liability and overall responsibility, they are other ways.

First, you have certifications. They already exist and can give ad-hoc solutions for some specific niches, and is the closest that we have to a license today. You can create a mechanism for someone to lose their certification if they commit a professional fault (even if this would totally be used in some case for internal politics and pressuring people in doing they don't want, irrelevant of any actual professional issues).

Second, you have transparency. Company can publish internal explanations of any disaster and if people are terminated because of it, they can make this public. Not that I like the idea... but it is a middle ground - where others are given an opportunity to decide if they to take the risk hire people with public failures, while not removing someone from exercising one's profession because some project went to hell and someone made mistakes.

Anyway, overall, I get his point that he want more responsible engineers on the job, but gatekeeping an industry with licensing sounds like a recipe for an even worse shit show.