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

41–50 of 128 posts

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

#41

Post by gchamonlive »

_bxg1 wrote: post #16
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…

None of the above changes the discussion. It's a very elaborate way of saying "writing correct software is hard". You know what's also hard to do correctly? Designing airplanes. Building skyscrapers. It's not that their designs are made flawless, it's that (in theory) the sheer volume of man-hours spent pouring over every minute detail of them, incorporating lessons learned from every failure that's ever happened in…

> it's that (in theory) the sheer volume of man-hours spent pouring over every minute detail of them, incorporating lessons learned from every failure that's ever happened in the field, amount to a very very high success rate

and this is what company executives need to understand. Given the fleeting nature of software and the speed in which one can write working code (not strictly correct or bug-free, but something that apparently works) people are convinced that software development should be cheap -- or cheaper than say airplane design. Software design is thus seen as cost not investment and those flaws in specifying and writing correct core is then shown in not treated edge cases, sometimes catastrofically

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

#42

Post by tashoecraft »

pjmlp wrote: post #37
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…

We could start by not allowing pseudo-engineers out of bootcamps. Yes, specs and tests don't cover everything, however without them software is much worse. I guess only an increase in lawsuits and product returns will eventually change the status quo.

Why? Because those with CS degrees don’t make mistakes either? Or how about self taught engineers, do they not count?

A problem is software is so easily created, destroyed and refactored. Combined with business interests pushing for all sorts of things midway through. How often are bridges built halfway when their entire spec changes, oh just convert his half done 2 lane bridge to a 4 lane double decker, should be no problem right? That’s how we treat software.

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

#43

Post by oldjokes »

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…

Typing systems and language choices are really small potatoes in this field. There are much more scary problems to solve to make software work right.

When you can side channel attack any CPU with a branch predictor and bits get flipped regularly by cosmic rays at high altitude then you need to rethink what software engineering really means. The big problems are rarely actually about the software or proving some algorithm is correct.

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

#44

Post by bcheung »

JoeSmithson wrote: post #26
_bxg1 wrote: post #16

Earlier quoted context omitted.

None of the above changes the discussion. It's a very elaborate way of saying "writing correct software is hard". You know what's also hard to do correctly? Designing airplanes. Building skyscrapers. It's not that their designs are made flawless, it's that (in theory) the sheer volume of man-hours spent pouring over every minute detail of them, incorporating lessons learned from every failure that's ever happened in…

Perhaps one of the reasons for this is that software doesn't allow humans any way of leveraging our evolved "danger detectors". It's hard to make a safe building, and it's hard to make safe software. The difference is it's (often) incredibly obvious that a building isn't safe the moment you step into it. In software it's sometimes pretty much impossible to tell the difference between a stone temple and a house of car…

It is incredibly obvious to people with the knowledge and skills. They can look at code and just by glancing at it can have a gut reaction that triggers red flags. Sometimes it can even be an emotional disgust. It's just not common knowledge. We as a community need to do a better job at transferring this knowledge.

Proper strong typing, not just the weak typing that is more common, provides these "danger detectors". It makes it a compile error. Compiler errors make things immediately obvious.

Type systems are very rich and most statically typed languages that are commonly used now can barely count as type systems when compared against what we know from mathematics and computer science. They merely describe the data format (or not in the case of nullable) and not acceptable inputs. They don't allow types for scenarios like requiring a function that exhibits these behaviors but not these other ones.

Pattern matching in combination with strong typing requires code that handles all possible inputs or you get a compiler error.

Dependent typing requires inputs to be within certain tolerances (not just adhering to a data format).

Type systems can also make certain race conditions impossible to create.

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

#45

Post by invalidOrTaken »

There's only one answer: exhaustive testing and attention to detail, NASA style. With NASA it's probably worth it. The rest of us, not so much.

Like efficax says, there's an oft-used analogy between software "engineering" and structural engineering that I think is way overplayed. The better analogy, IMO, is between software and business.

What "CEO" means is basically "authority and responsibility." We have some guardrails called laws, but outside of that we acknowledge that "CEO'ing" is a complex, ambiguous task requiring personal judgment, and is not reducible beyond that.

"How careful should we be?" is a question with some interesting characteristics:

- it's a matter of opinion. How risk-averse are the shareholders?

- it's a matter of context. On the CSS for the company promo site: eh. On the embedded code running the flight-control system---very. But what if that stems from MVP code that originally ran in a simulation on the company promo site?

I mean, what you really need here, is for your board members to write the code.

I'm speaking tongue-in-cheek a bit, but I'm not sure it's 100% wrong, maybe just 75%. In a very real way, the authority-responsibility-reward lineups are so out of whack in most organizations. Which is not to say I know what they should look like.

(Two words I need to think about more: "Software insurance")

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

#46

Post by bcheung »

oldjokes wrote: post #43
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…

Typing systems and language choices are really small potatoes in this field. There are much more scary problems to solve to make software work right. When you can side channel attack any CPU with a branch predictor and bits get flipped regularly by cosmic rays at high altitude then you need to rethink what software engineering really means. The big problems are rarely actually about the software or proving some algor…

Ah yes, real engineers anticipate the side channel attack that can happen when someone releases a butterfly at precisely the right location and precisely the right time so that it flaps its wings that affects the climate 10 years later that affects the cosmic rays that cause electrons to misbehave in all the CPUs across all the Docker containers on all the hosts in all the data centers and availability zones that causes all the right double entry debits and credits across multiple bank accounts and across multiple banking companies to steal some money.

This is a much bigger problem than type safety.

But luckily that is a hardware problem.

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

#47

Post by airbreather »

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 attempt to produce critical software to an estimated known quality.

When you do the calcs the equipment is usually the easier part, it is almost always the humans that end up causing the problems. It is amazing how creative they can be to do a task, or to not do a task.

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

#48

Post by sanderjd »

_bxg1 wrote: post #16
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…

None of the above changes the discussion. It's a very elaborate way of saying "writing correct software is hard". You know what's also hard to do correctly? Designing airplanes. Building skyscrapers. It's not that their designs are made flawless, it's that (in theory) the sheer volume of man-hours spent pouring over every minute detail of them, incorporating lessons learned from every failure that's ever happened in…

I think there is agreement, or at least slowly developing consensus, that some software should be "engineered" and some should just be "developed". But there is not yet really a structure (that I have seen) for declaring which thing your project is doing and setting up your practices accordingly. One reason this is tricky is that many (most?) projects start in the should-be-developed category and only transition to the should-be-engineered category later after they become mission critical in some way. The answer is often to build an "engineered" version as soon as you can figure out you need it. But then that's even more expensive than doing it that way to start, and it's also a really tough call to make because everybody knows rewrites are a bad idea. It's a tough bind for all but the most obvious cases. And then because those obvious cases are fairly few and far between, the best practices and the experiences of most of the workforce are skewed toward software that merely needs to be "developed".

To make this concrete: a couple times now in my career I've embarked on projects where setting up any level of formal verification at the beginning would have clearly been overkill, but where a few years later I really wished I had it for certain important pieces. And now since formal verification is so uncommon in my experience, I would have to play a lot of catch up to do it, even for a project that is clearly important enough for it even from the beginning. I think this is a pretty widespread experience.

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

#49

Post by maximus1983 »

degenerate wrote: post #15
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…

I've heard the analogy of a software developer to a mechanic, and I like it much more. Developer = Mechanic Computer = Car Make = Language Model = Platform Year = Version A mechanic is licensed by ASE to work on cars in the USA and there are 50 different certifications [1], depending on the type of car/truck/bus. I don't want to see software development go this route, where developers have to get multiple certificati…

I don't like car analogies.

A software engineer is like a plumber you link up lots of small components, weld them together and then the data flows through the application (at least that is the idea).

Post reply on HN