Hacker News Reader

Comment by jack_riminton | Hacker News Reader

Whilst I agree in principle, would any Senior Engineer want to work on such a system that had their personal liability attached? I'd want 10's of millions in annual comp just for the risk

View on HN

Yes? Plenty of non-software engineers do it daily.

You start off by having a Professional Liability insurance policy, your company will generally pay for it unless you are a consultant/contractor in which case you bring your own policy. Depending on size of operation, your employer may even indemnify you in the employment contract specifically for even negligence lol.

You then do your job correctly. The laws only go after you for liability if you were negligent, i.e. you skipped protocol and policies, you skipped best practices and couldn't justify it, etc. If you weren't negligent and just made an error, great, your insurance covers you. Insurance can also cover negligence too depending on policy, lol

https://www.nspe.org/resources/professional-liability/liabil...

Yes and they do non-software engineering

Are we going to have international protocols and policies on the best language to use, how to do SQL queries and CSS? no

Professionally qualified engineers in other fields seem to manage OK?

And on top of all-certified components, it also requires the chief engineer to have veto power over the system. If business or client asks for features that are potentially insecure (and that's going to be a lot of features), they have to accept being told 'no'. I'm not seeing that happen easily in the software industry.

This is chicken-and-egg though, surely. If engineers are not personally liable for the garbage they produce, the business can replace the engineer with someone more amenable to their requirements (either because the engineer lacks experience to understand why its bad, or because the engineer has fewer scruples, or anywhere in between) with relative ease.

If all engineers are held personally liable for their code, when a business has faced a documented rejection, they’ll struggle to hire someone else to take on that risk.

You're right, and it would radically change the industry. No more wild experiments, but a very measured and ponderous rate of change. It's not necessarily a bad thing, I'm at the age where I curse aloud when I see yet another framework doing nearly all the same things but in a different way, but it's certainly a big change.

You'd still be allowed "wild experiments" - just not where they could harm people.

"Harming people" includes money loss, though. Any hacking that results in identity theft would end up at the feet of the certifying engineer.

Good, then maybe it'll be a forcing function for companies to stop collecting personal data for their users just because they can, and we can go back to the days when the only metadata associated with an online account is its salted and hashed password.

You mean a hospital next door to an ammonium nitrate godown and 23andMe will be rejected by the same actuaries?

the german supreme court just recently decided that the involuntary publication of personal data like your phone number through a break-in already constitutes damage that the companies who experienced the break-in are responsible for. there is no need for certified engineers, just make the companies pay for being negligent. putting this on certified engineers only shifts the blame, but in the wrong direction in my opinion, because these problems happen not because the engineers are not certified, but because the company tried to save money by cutting corners.

I'm not sure what you're arguing for then. Continue apace, where I get a letter every week about entire reams of my personal info leaked because some imbecile didn't set a password on their MongoDB instance?

> they have to accept being told 'no'

They can always hire another engineer. They only accept it, some times, because they won't find a certified engineer that says "yes", and because they doing it themselves is a crime.

That equates to a huge amount of government intervention on the lives of everybody. And even then, fails way more often than expected.

Now, we are talking about a case where criminal justice failed to uphold the defendants rights to a fair trial. Most probably because of corruption. Do we really want to bring that huge amount of government intervention into this context?

They work with certified components on predictable systems though.

You realize that you'd need someone at MS to take liability for Windows before you can sign off anything running on Windows?

Or someone at Google if you do a web app that only runs on Chrome, not to mention other browsers.

Some systems must have these certifications.

What OS renders the monitoring screens for air traffic control systems, or railways signalling? Those both have rigorous software engineering behind them — railway signalling is the original of engineered, safety-critical logic systems, starting with mechanical interlocks in 1843. (The signalman physically couldn't move certain levers into bad configurations.)

Well yeah, but the fact that no one takes responsibility for anything and just smears layers of crap on top of each other is the problem. We have build enormous houses of cards on foundations of quicksand and its causing very real harm, but no one cares because the only thing they'll face consequences for is drops in story points on their sprint or whatever else and nothing for failing to do things that actually matter.

Yes, that is exactly part of being a Professional Software Engineer entails, and why there are universities assessed by Enginnering Order, and professional exams.

Lets stop glueing "engineering" to any job title where someone knows how to write a bunch of code lines.

The important bit is that if you screw up badly enough then your professional qualification is removed and you can't do that type of work any more.

[NB I am frequently reminded of this point by my wife who is a solicitor].

I am aware of that, because I happen to be from a country with an Engineering Order.

Another important part is that one might be liable when signing contracts as the responsible Engineer in a project delivery.

Don't understand how this isn't the dominant perspective on this.

This title inflation of calling web programmers "engineers" is absurd.

The real problem is who could afford a system that a competent senior engineer would take personal liability for...

The real problem is our entire industry is a giant clusterfuck. Do a 2-week bootcamp, congratulations now you're a software engineer.

Every other discipline has education requirements, codified standards for how to do things etc.

Thankfully not every country out there has such liberties with "enginnering" titles, but yeah that is a problem.

It's not the title that's the problem. It's the part where people and go write software that gets deployed at scale in an environment where bugs can cause very real and significant damage (monetary or otherwise).

The title is part of the problem, because it reveals the culture, slapping cool titles without upping oneself to what those titles actually mean.

As for the rest, anything that brings computing to level of the rest of other professionals, has my signature.

A Software Engineering professor of mine used to say, many applications are akin to buying shoes that randomly explode when tying shoelaces, whereas a minor defect on real shoes gets a full refund.

> The title is part of the problem, because it reveals the culture, slapping cool titles without upping oneself to what those titles actually mean.

The irony is there are actual disciplines in software that are worthy of being called "engineering"--how the hell does an engine ECU work with the level of precision that it does? ABS systems? Hell, how about most electronic control systems on an airplane?

These are some of the most impressive feats in software development, and I've heard near 0 about any of them.

Yet the "industry" is hyper-focused on mashing together "containerized" monstrosities to put strings in databases, or to find a new way to add a chatbot to something that doesn't need it.

I'd argue that really says more about capitalism, wealth distribution, and the financialization of everything, as opposed to software stuff per se--

In another area it might be the complete insufficiency of formal botany credentials among Dutch companies growing and trading tulips.

> codified standards for how to do things

I don't know you but i bet that if you and me were locked up in a room together for a month we wouldn't be able to 100% agree on "codified standards for how to do things" :)

Industry isn't mature enough for that and it's perhaps doubtful that it will ever be. See the halting problem.

> 100% agree

I don’t think it’s necessary to agree completely. You could start by codifying a minimal set of things that the majority of people agree on (user data sanitisation, authentication handling etc) and then build on it over time.

The standards could also help codify more meta things, like vulnerability policies, reporting and outages. This would be helpful to form a dataset which you can use to properly codify best practices later.

The main problem is that this increases the bar for doing software development, but you can get around this by distinguishing serious software industries from others (software revenue over a certain size, industries like fintech, user data handling etc)

ye gods, can we come up with a "law" to describe appealing to the halting problem?

Just because there are unanswered questions that doesn't mean we can't have bare minimum codified standards.

Furthermore, standards aren't invalidated just because practitioners disagree with them. Plenty of <insert engineer type>s disagree with the standards body of their respective field, they still follow the standards out of fear of prosecution or simply as a path of least resistance and when those standards are found to be defective, they (generally) evolve.

> we can't have bare minimum codified standards

So, functional, imperative or OOP? :)

> Just because there are unanswered questions

The halting problem is undecidable. Not undecided. I.e. it has been solved and the answer is "you can't".

This is the most pedantic sort of semantic navel-gazing that can only originate in the bowels of an HN thread. Bravissimo, truly.

Yep, now answer me the part about functional, imperative or oop, and come up with a plan to convince everyone.

We don't need to solve the halting problem. We just need to come up with a sensible set of practices that, if followed, make the risks small enough to be considered acceptable. Then we can point at that list and say, "this is what the reasonable expectation of due diligence in software engineering is" - and legally enforce that.

The industry will be 80 years old soon. If it's not "mature enough", it's only because of the pervading culture.

For comparison, electrical engineers started introducing things like national standards for plugs by 1915.

Plugs? You mean various forms of rpc and more or less well specified data interchange formats like xml or json? We have them.

XML and JSON is more like standardizing the voltage (and even there the fact that we still have both shows that it's very much a moving target).

Professional liability insurance and legal insurance as a minimum.

I'm fairly sure Fujitsu do have liability insurance in some form.

In a situation like this an insurer is strongly motivated to prove that the company is not at fault, because it doesn't want to pay the bond. The company is also strongly motivated, even though insured, to prove that the company is not at fault, because it doesn't want to have its future insurance rates affected or be sued by the insurer for breaches of terms.

Either way, it doesn't help the people affected. Not unless they have personal insurance against workplace computer system errors, in which case their insurance provider is also not motivated to pay out, or to battle a corporation as large as Fujitsu unless there's chance of a class-action suit.

Reply on news.ycombinator.com