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

31–40 of 274 posts

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

#31

Post by always_good »

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.

Well, it's a whole ecosystem problem. Most of the places I've worked, security was just supposed to be something you learned and credentialized on your own, and no time or resources were deliberately allocated to it.

In fact, you're likely seen as an underperformer if you slow down to get things right or to refactor bad code. And when software does break, `git blame` tends to accuse the developer that was in the worst position to fix a ship that had begun sinking long ago.

I'm not sure how engineer culpability works in other fields, but surely it's always coincided by bad process and management at which point the whole company is responsible.

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

#33

Post by gregmac »

nomel wrote: post #23
tmnvix wrote: post #3

> "Programmers were like chess players trying to play with a blindfold on—so much of their mental energy is spent just trying to picture where the pieces are that there’s hardly any left over to think about the game itself." This is an insightful description of the biggest mental challenge I face when programming.

My personal method is, every line of code that I write, I write for someone else. If it's internal, it's always for another developer (who may not exist) and, for the upper layers, a user (of the function/API/library) that may peek behind the scenes trying to debug some problem. If it's anything facing the "user", it's entirely written for that user, and I know they're not very good at reading or writing software. Th…

> for another developer (who may not exist)

You, 6 months from now (or whenever you stop touching this code base), are effectively "another developer".

New developers don't seem to really grasp this until the first time they have to maintain their own old code. I don't think it really hits home until the first time you experience: "What is this? Who wrote this garbage??" runs git blame "..oh, crap."

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

#34

Post by vtange »

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…

I'm pretty sure less people would be rushing into the software engineer profession if they knew it came with the liabilities you described. That would drive up the prices of engineers.. and I'm pretty sure the industry in general doesn't want that.

Maybe that's why the free pass mentality exists

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

#35

Post by Epenthesis »

Jtsummers wrote: post #12
jasonmaydie wrote: post #10

Earlier quoted context omitted.

it's like blaming the assembly line worker for a badly designed car. Software engineers don't solve problems, they implement solutions someone else thinks will solve a problem.

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)

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

#36

Post by User23 »

FrancoisBosun wrote: post #26
combatentropy wrote: post #6

If TLA+ really does let you prove your program is bugless, then maybe it is something to look into for cars, airplanes, medicine, etc. For the rest of us, who still wrestle with complexity but probably would't accidentally kill someone, here are some simpler aids: 1. Don't put a computer there. My microwave doesn't need to be digital. It needs two dials, time and power. My mother's washing machine can be controlled b…

Smartphone controllable light switches and blinds are useful for disabled people.

Modern smartphones are an incredible accessibility device for the both partially and fully blind persons. The freedom they offer is virtually unimaginable to people who haven't seen the different they make in people's lives.

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

#37

Post by tener »

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…

Broken software does not typically kill people or makes you loose money (time or some other resources, maybe).

In contrast bridges that fall apart tend to kill people in a nasty way. They are also quite hard to reboot.

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

#38

Post by emodendroket »

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…

Without radical, NASA-style changes to typical development, where each line spends much more time being audited than being written, it is completely unreasonable to expect that kind of liability from developers.

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

#39

Post by 0xdeadbeefbabe »

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.

What evidence supports this as the only difference? I would argue these other engineers have significantly smaller jobs to do, so it's easier to be thorough.

Edit: Why are you so keen to fix a problem you don't understand? Are you a programmer?

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

#40

Post by amiga-workbench »

emodendroket wrote: post #38
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…

Without radical, NASA-style changes to typical development, where each line spends much more time being audited than being written, it is completely unreasonable to expect that kind of liability from developers.

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.

Post reply on HN