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

Programmers who want to change how we code before catastrophe strikes

theatlantic.com

Post reply on HN
Print view View original

51–60 of 274 posts

Re: Programmers who want to change how we code before catastrophe strikes

#51

Post by scintill76 »

Bartweiss wrote: post #43
chroem- wrote: post #24

The dangerous unreliability of software is an accountability problem, not a technology problem. Engineering disciplines are regulated so that engineers are held personally and even criminally responsible if they endanger property or lives. Software, being the newcomer, has no such regulation. Instead we have people trying to claim that software deserves a free pass from due diligence because "software is hard," when…

> The only difference is that these other engineers are motivated to be significantly more thorough about their jobs. Hang on. Sure, all engineering has hurdles. But how many engineering projects face regular enemy action? The last time somebody actively tried to compromise a system I was building was two weeks ago. How many engineers live like that? We hold civil engineers responsible when bridges collapse unprompte…

Most of the article, and the comment you're replying to, wasn't about hackers, though. It gave the example of people dying because the Therac machine or a Toyota car responded wrongly to non-malicious, normal user input, like a "bridge collapsing unprompted" in normal use.

Re: Programmers who want to change how we code before catastrophe strikes

#52

Post by Bartweiss »

emodendroket wrote: post #44
amiga-workbench wrote: post #40

Earlier quoted context omitted.

Ditch the dumb deadlines and the tight budgets and it would become a hell of a lot more feasible. I WISH I had the time and budget to put due diligence into my work.

You have to think about what you're building too. Feature release would come much slower than it does today. Reasonable? If you're writing software that is absolutely safety-critical, that's likely. If you're writing iTunes, well, I have my doubts.

It's not like reliable, secure software doesn't exist. It's just limited to spaces where people are willing to use years-old tech, forgo new features, and pay fortunes for auditing. Air travel, industrial machinery, medicine, and so on.

Almost like the cost-benefit actually doesn't support making the development of trivial software ten times slower and more expensive...

If there's a problem here, it's business externalities (Equifax won't pay adequately for screwing people), not engineering impossibility (the rest of us know how to patch Apache).

Re: Programmers who want to change how we code before catastrophe strikes

#53

Post by drinchev »

chroem- wrote: post #24

The dangerous unreliability of software is an accountability problem, not a technology problem. Engineering disciplines are regulated so that engineers are held personally and even criminally responsible if they endanger property or lives. Software, being the newcomer, has no such regulation. Instead we have people trying to claim that software deserves a free pass from due diligence because "software is hard," when…

Regulation on programmers is not the solution.

Regulation on companies might be. I'm usually really disappointed when a cheap re-seller takes a government purchase of a 911 or 112 ( here in EU ) and then hires a subcontractor, which hires a subcontractor, which ...

That's how crappy software gets into production.

Re: Programmers who want to change how we code before catastrophe strikes

#54

Post by imh »

chroem- wrote: post #24

The dangerous unreliability of software is an accountability problem, not a technology problem. Engineering disciplines are regulated so that engineers are held personally and even criminally responsible if they endanger property or lives. Software, being the newcomer, has no such regulation. Instead we have people trying to claim that software deserves a free pass from due diligence because "software is hard," when…

Can't it be both a technology problem and an accountability one? The tech problem might take ages to get solved without accountability forcing it. If we were accountable, we'd be forced to make better tools for writing reliable software more easily. That said, there are simpler low handing fruit "tools" like code review, safe git practices, etc that still aren't followed everywhere. Ignoring those low hanging fruit does point to accountability/prioritization being a cause of low reliability.

Re: Programmers who want to change how we code before catastrophe strikes

#55

Post by emodendroket »

Bartweiss wrote: post #52
emodendroket wrote: post #44

Earlier quoted context omitted.

You have to think about what you're building too. Feature release would come much slower than it does today. Reasonable? If you're writing software that is absolutely safety-critical, that's likely. If you're writing iTunes, well, I have my doubts.

It's not like reliable, secure software doesn't exist. It's just limited to spaces where people are willing to use years-old tech, forgo new features, and pay fortunes for auditing. Air travel, industrial machinery, medicine, and so on. Almost like the cost-benefit actually doesn't support making the development of trivial software ten times slower and more expensive... If there's a problem here, it's business extern…

I mostly agree, but this article cites the national 911 software, which arguably should be treated as a critical system, failing, and some medical devices whose software killed people.

Re: Programmers who want to change how we code before catastrophe strikes

#57

Post by Clubber »

Epenthesis wrote: post #35
Jtsummers wrote: post #12

Earlier quoted context omitted.

The analogy would be more appropriate if you said programmer and not software engineer. Anyone calling themselves a software engineer should be providing input into the design of the thing they're producing. Their role is very explicitly managing requirements and codifying them in, well, code. Either directly doing the programming or managing those who do.

Are there companies that actually distinguish between these roles? For all the ones I've ever worked at, "software engineer" and "programmer" are synonyms. (I'm aware that there's been some effort to extend the legal significance of the word "engineer" to the software industry, but I'm curious if that difference is actually in practice anywhere today)

I dunno, it's just a title game. I would guess it's because programmers in the 90s simultaneously had massive hubris and insecurity issues and wanted to be just as respected in the community as actual engineers, but who knows.

Engineer invokes a sense of design, but so does programmer. When I started, there was no job where you just coded straight pseudocode specs. Business described the problem the way business does, and you had to convert that into a computer solution. Within that solution, different developers would own various parts of it.

I would say the entire process of having coders who design systems and coders that just write code is inherently broken. Businesses want to think of development as prod-ops, but it's more like book publishing. I'm of the mind that if a coder who designs a system in enough detail to write pseudocode, he should just write the application.

The better approach is have an architect/lead model subsystems and a general skeleton of the application, then have different teams implement the subsystems. Clearly defined interfaces on all inter-subsystem communications.

Re: Programmers who want to change how we code before catastrophe strikes

#58

Post by skywhopper »

This article is silly in a lot of ways. The real problem of software engineering is not "how do you prove this code follows algorithm X exactly?" It's "how do you know what algorithm X needs to be in sufficient detail to implement it?" It's "when you realize you were wrong about algorithm X, how do you change your existing, working code to implement the new algorithm X-prime, without interruption?" It's "what do we do when we realize algorithm X-prime was completely the wrong thing, and now we need to transition to algorithm Y, and also fix all the data that algorithm X-prime messed up?"

No matter what awesome tool you come up with to translate requirements into CPU bytecode, you still have to translate human requirements into that requirements language, whether that language is assembly, C, Java, Rust, Haskell, or TLA+.

When you have the money and time and patience to fully examine the problem space and work out exactly what the requirements are, that's great. In the far more common scenario, you have impatient investors, or you're inventing something entirely new, or your software will deal with the real world which is not as predictable as an imaginary algorithm. Government regulations, flaky hardware, network latency, human error, financial limits, competition, malicious actors, gamma rays, other people's software, power outages, terrorists, dependencies, operating system upgrades, corrupt data, hurricanes, all are conspiring against your software. Can you plan for all of that?

Re: Programmers who want to change how we code before catastrophe strikes

#59

Post by haskellandchill »

vtange wrote: post #49

So we need to write more code to make fancy Photoshop-like editors for the average-Joe programmer who can't see the big picture? That just adds more to the code issue - even Photoshop has bugs you know. The fact that "Few programmers write even a rough sketch of what their programs will do before they start coding" is a soft-skills/experience issue that isn't specific to software. I too can use Photoshop to draw logo…

No, we need to use logic and set theory and provide tools for visualizing the implications of our rules and checking correctness of desired properties. There's a strong history and lots of good people working on these things but it's tough to get our message out to working programmers. This article helps but based on the comments we've got a lot of perception work to do :)

Re: Programmers who want to change how we code before catastrophe strikes

#60

Post by justherefortart »

david927 wrote: post #30
Animats wrote: post #25

Earlier quoted context omitted.

What went wrong with Visual Basic? (HTML/CSS/Javascript was botched so badly that Dreamweaver-type editors no longer work. This is embarrassing.)

What went wrong with Visual Basic? The language was simple enough for beginners but not sophisticated enough to scale for large projects. All too often you would have a project that started in VB as a proof of concept which then extended to become the actual system, and then as that system grew it started to collapse under its own weight. The conversion to the CLR fixed a lot of that, but now it isn't really for begi…

Visual Basic was fantastic for kicking out a UI. If you needed anything larger, all you had to do was build DLLs and reference them. So easy front end and easy back end. The best of both worlds.
Post reply on HN