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

41–50 of 274 posts

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

#41

Post by emodendroket »

vtange wrote: post #34
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

Or maybe the "free pass mentality" exists because development doesn't happen in a vacuum and errors don't necessarily find their way into programs because the programmers are stupid or careless.

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

#42

Post by narvind »

Great article!

My $0.04:

1. Programmers often see a small part of the jigsaw puzzle they are assembling. Most spaghetti code is the result of too many cooks over time.

2. The architects should ensure that testers know and care more about the problem than the programmers who are coding the solution

3. There is a clear need for improving the stone age tools programmers use

4. There is a need to create simulated environments for all kinds of software so they can be battle tested

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

#43

Post by Bartweiss »

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 unprompted. We also hold them responsible if their bridges fail from some minor, anticipated harm like vandalism or a car crash. We don't hold them responsible for building bridges that can be blown up.

If we want to hold software developers accountable for downtime, unprompted data leaks, and so on, fine. We should do it proportionate to the damage caused - there's no point in pretending that a shoddy smartphone game is as bad as a shoddy bridge - but fine.

But let's not pretend that software has the same difficulties as every other type of engineering. Most engineering doesn't face an epidemic of people actively trying to disable safety precautions to hurt people, and a lot of it reliably fails as soon as it does face enemy action. Punishing every engineer who ever gets outwitted (say, by a leaked NSA-developed vulnerability) is absurd.

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

#44

Post by emodendroket »

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

Earlier quoted context omitted.

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.

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.

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

#45

Post by mannykannot »

brfox wrote: post #13

The article didn't mention it, but I think that Excel is a great example of where "the masses" have learned to do programming. It is visual and the effects of changes are immediate.

The effects of a change may be immediate, but not necessarily immediately obvious. Subtle bugs are a problem in any programmable system.

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

#46

Post by emodendroket »

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…

Beyond that, the organization they're in sets the priorities; how is it going to fix anything if the engineers are on the hook for Equifax leaks but they still have the same (presumably not very security-conscious) managers?

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

#47

Post by jakelarkin »

jasonmaydie wrote: post #10
DrScump wrote: post #2

“Software engineers don’t understand the problem they’re trying to solve, and don’t care to.” In environments where management judges by (and is judged by) other metrics, this result is inevitable.

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.

Was thinking about this the other day: in big companies SWE individual contributors are the new line workers. Large enterprise ends up trying to manage them with business metrics goals without much visibility into the process issues that hamper overall quality or the production efficiency. Has anybody thought to apply the Toyota Production System in Engineering management?

https://en.wikipedia.org/wiki/Toyota_Production_System

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

#49

Post by vtange »

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 logos, maps, and diagrams, but I'm pretty sure someone out there who uses Photoshop professionally knows a lot more tricks within Photoshop and sees the bigger picture of what they want to create before starting. I generally free-hand my drawings, as opposed to the structured outlining most professional artists do.

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

#50

Post by Bartweiss »

tener wrote: post #37
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.

An excellent framing I saw recently was "I can tell the people who write these articles don't actually want secure code, because they aren't paying me to write it."

There's plenty of carefully-written, rigorously-tested code out there. Want to write software for air travel, drug manufacturing, or space flight? You'll have no choice but to write safe, first-rate code.

Want a smartphone weather app written to those standards? Well, for $50 and a feature set five years behind the state of the art, you can have it.

Post reply on HN