Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Should We Do to Prevent Software from Failing?

sloanreview.mit.edu

Post reply on HN
Print view View original

111–120 of 128 posts

Re: What Should We Do to Prevent Software from Failing?

#111

Post by danielscrubs »

efficax wrote: post #10

The analogy between software "engineering" and structural engineering is used a lot to point out the failures of software. I think this analogy is a category mistake caused entirely by the misapplication of the word "engineer" to software developers. We have already solved large areas of common classes of bugs at the language level, through strong static typing, memory safety and safe concurrency (Rust is the vanguar…

In my country, all engineers are protected titles and basically just says you spent half of your 3 or 5 years studying math. Not even algorithms, just math. Makes it very confusing when teens calls themselves SEs

Re: What Should We Do to Prevent Software from Failing?

#112

Post by carlmr »

nerpderp82 wrote: post #88
carlmr wrote: post #78

Earlier quoted context omitted.

I think that's the key. There was ADA now there's Rust. If you can have GC on your system there are plenty of other languages that make strong static typing and other compile time guarantees that beat any analyzed C++.

Our safety critical languages need to be simpler, so they are amenable to mechanical proofs and exhaustive model checking. Dimensional units would be a good start. https://gmpreussner.com/research/dimensional-analysis-in-pro...

F# has those built in (not mission critical embedded ready, but a very very nicely designed language).

ADA hat strongly typed fixed point built in. Rust I think has a strong enough type system to implement this as a library, at least there seem to be a few.

Idris also looks interesting. Maybe something like this can be done with dependent types.

Re: What Should We Do to Prevent Software from Failing?

#113

Post by carlmr »

dnautics wrote: post #106
carlmr wrote: post #78

Earlier quoted context omitted.

I think that's the key. There was ADA now there's Rust. If you can have GC on your system there are plenty of other languages that make strong static typing and other compile time guarantees that beat any analyzed C++.

Is static typing really what you want? I would think that if you want safety against failure, you really want redundant systems that live in separate failure domains and can coordinate in the event of failure.

Why can't you have that with static typing? Btw I think only strong static typing really helps (C is statically typed but allows way too many implicit conversions).

There's also the question of what you regard as safety. Fault tolerance (like in elixir/erlang), or a design for fewer faults (e.g. ADA/Rust)?

Fault tolerance is good for high availability, which can be a safety goal (e.g. What does your airplane do when all the computers are off?) it doesn't help you however if yoir software didn't crash but does the wrong thing (like the boeing).

For the second part, strong static type systems definitely help, they provide clear documentation what can and can't be done, and they cause as many compile time errors if you do the wrong thing as possible. It doesn't rule everything out, but it gets you closer to the goal of correctness.

Fault tolerance is still needed. Usually you want to have redundancy (I think most airplanes use 5 controllers calculating at the same time to prevent atmospheric radiation causing bit flips to cause issues). And you want the system to go into safe states (e.g. Detect a fault and reinitialize, if that doesn't work do your best to stay operational until you've reached safety).

I think we could probably take over some of the supervision ideas from elixir, but combine it with strong static typing guarantees.

Re: What Should We Do to Prevent Software from Failing?

#115

Post by kkarakk »

naringas wrote: post #4

ah, here we go fast forward 25 years and we'll need a government approved license to open dev tools in a browser. I hope I am wrong.

Sure there will be a bypass available on the black market which every kid will pass around to each other as a matter of course. software isn't the same as hardware, it's almost impossible to limit access unless you go full on draconian government - which might happen,granted.

Re: What Should We Do to Prevent Software from Failing?

#116

Post by airbreather »

BeetleB wrote: post #92
airbreather wrote: post #47

Certification already exists - called Functional Safety Engineer, issued by people like Exida and TUV. I hold this Certification. It is painfully slow to use performance based standards to extract users risks and needs and then produce software designed and tested to standards like IEC 61511 and IEC 61508. They are basically Q/A standards, encourage use of the V-model, defined life cycle activities etc etc in an atte…

Kind of sad that out of 83 comments, only 1 mentions "functional safety". If you want to write SW for, say, cars, ISO safety standards exist, and you generally get your work and development audited by a 3rd party agency who will confirm whether you've conformed to the safety standards. Conforming to those standards is not fun. And obviously, conforming to them doesn't mean your SW is actually "safe". If most engineer…

Yeah ISO 26262 is a derived standard from the parent 61508, as is 61511 for process sector.

It is all about risk management, probabilistic outcomes and not spending all your money on a highly visible/emotive risk and ignoring an equivalent risk that is pervasive but lower consequences.

A day to day example of how humans can be poor at intuitively allocating risk and avoidance is the immense fear some people have of the shark attack or plane crash, when they are statistically at way more risk driving to the beach or the airport, but think nothing of it. (Cars can be mighty convenient though).

In my case risk decisions are usually driven by the company risk matrix as to tolerable risk, the companies way of conveying the enterprise wide appetite for risk.

The risk matrix is also known as "the death quota" because it actually says how much is the maximum they are prepared to spend to avoid a fatality, or multiple fatalities, but you are never popular with the client when you frame their risk aversion guidance in that manner, not at all.

Usual guidance is that the company wants no real increase of risk of harm to employees as they experience in general public day to day life, around 1x10-5 chance of death per year in western countries.

Not thinking this sort of risk is part of the day to day thinking of most SV software engineers, because the consequences of your Uber going to the right street in the wrong suburb are undoubtedly significant to someone at the time, hardly likely to be life ending.

Re: What Should We Do to Prevent Software from Failing?

#118

Post by repolfx »

bluntfang wrote: post #96
jacobsenscott wrote: post #90

Earlier quoted context omitted.

Writing software is not engineering - engineering is building the same thing over and over again and you slowly learn how to do it the right way. There are incremental improvements along the way - stronger lighter materials, better tools, etc. But the folks who built the Roman aqueducts could get up to speed pretty quickly on the Golden Gate Bridge. The principles of flight don't change. The fundamentals of building…

>That's what software is - every project is a brand new thing that has never been done before - there isn't 200 years of learning to fall back on. Sorry but this is just gatekeeping bullshit. Most apps being built today by companies with the budget to build them are TODO apps, report apps, storefronts, big data mungers, CRMs, etc. They all just have different business requirements and domain specific knowledge. To th…

Yeah, and a lot of that software sucks because the companies who pay for it to be developed want the cheapest possible thing that just about works and not some ultra-engineered unkillable concrete bunker of an app that costs them 50x more. That was the entire point of the agile revolution - get rid of waterfall methods inherited from classical physical engineering and switch to constant iteration and shipping, with fixes to not-quite-right work being done whilst workers are in the building. Software engineering became less like regular engineering because that's what the customers wanted, and who's to say they were wrong?

Re: What Should We Do to Prevent Software from Failing?

#119

Post by repolfx »

pbourke wrote: post #93
bgorman wrote: post #77

Earlier quoted context omitted.

Look at teaching in the United States. All states require teacher licensing at public schools. However private schools do not and get better outcomes. Same thing with many unions for trades. I have yet to see any evidence a union electrician or plumber is better than a non-union worker, however unions do all they can to keep competition off the market.

Would you be willing to be treated by a Doctor without a medical license or be represented by an attorney who hasn’t taken or passed the bar exam?

Me? In a world where such licenses were not mandatory, i.e. the doctor in question wasn't actually breaking any laws? Sure.

I'd probably want some alternative evidence of competence of course, like a long stream of happy, healthy, cured patients who could vouch for him. Or alternatively some sort of private sector approval scheme, based on trademark licensing. Sort of like how you can't claim a phone supports Bluetooth unless it's been licensed and approved.

But in general I don't see any reason to assume the specific licensing regimes in place today are so grea.t

Re: What Should We Do to Prevent Software from Failing?

#120

Post by jdmichal »

bluntfang wrote: post #107
jacobsenscott wrote: post #101

Earlier quoted context omitted.

I honestly don't know what gatekeeping means in this context. > all just have different business requirements and domain specific knowledge Yeah - that's what I said. You realize that's where all the complexity is, right?

>I honestly don't know what gatekeeping means in this context. you're trying to create a barrier to standardization. You don't want to codify successful patterns to keep your job coveted. >Yeah - that's what I said. You realize that's where all the complexity is, right? That's not what you said.

You're being extremely uncharitable.

Look, business processes are different at every single company. Especially between companies doing the exact same thing. Which means that the software ostensibly doing the exact same thing at each of these companies is going to vary dramatically. Because the software at a company aligns to the business processes of that company. This is the true heart of Conway's law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

And there is no fixing this. It's baked directly into the axioms. If every company in a domain ran exactly the same way, there would be no such thing as a competitive advantage.

Post reply on HN