Hacker News Reader

Comment by tomatotomato37 | Hacker News Reader

I know this is mostly over how important it is not to have anything voting/democracy related fail horribly, but going after the comment in the fourth panel what exactly happened to our field that we can't generally be trusted to make something that works? Is it just "Move fast and break things" in action?

View on HN

Architects and mechanical engineers not only know about blueprints and design procedure, they also have a solid understanding of the physics that make their designs work. Programmers, by and large, just know how to code.

There exists a formidable body of study describing the practices and theory required to write knowably-correct software, but the software engineering industry treats these ideas with utter derision. Even lighter-weight methods for knowably preventing broad classes of errors(e.g. Haskell-like type systems) are considered niche and pretentious. These opinions are mirrored by many CS programs, so most engineers wouldn’t have the slightest clue how to apply these methods, or even know that they exist, should they decide they were necessary.

With that kind of culture, what can we expect?

Here, the problem is we can't trust users to not try to break the system. When I buy a plane, I don't want the plane to crash. When I buy a voting machine, I'll do everything I can to break it so as to earn more votes than I deserve.

It's a rare case of a system its main customer does want to be able to break.

Now, of course we can make things that work. Airplanes and elevators are computing devices too, after all. But a working software is as expensive as a working airplane. People don't want their word processor to cost millions of dollars. OpenOffice is free, MS word is a few bucks, what do you expect?

> It's a rare case of a system its main customer does want to be able to break.

Many people would be happy to break ATMs or banking software.

And indeed, they're happy to do just that.

https://www.wired.com/2016/05/insane-81m-bangladesh-bank-hei...

The main customer of an ATM is the bank owning it. Not sure if "customer" is the correct word, let's say "owner", as opposed to "end user".

"Now, of course we can make things that work. Airplanes and elevators are computing devices too, after all."

Funny you should say that. Yesterday, the buttons for our elevators crashed. Nobody could hail elevators on the touch-screen thing. Because software. Name the last time an actual elevator crashed.

> Name the last time an actual elevator crashed.

They do it like every day, if, as is the case for software, you use “crash” to mean “experience a sudden and complete cessation of operation.”

They also do crash in the rather more extreme physical sense occasionally, e.g., https://www.thehindu.com/news/cities/Delhi/3-injured-in-elev...

In countries with lack of proper regulations elevators are crashing more often, that's what I would expect. But I don't think elevators crash as often as software in India.

There was an incident with someone using an elevator here in Portland, Oregon, a few years ago, IIRC not a sudden stop at the end at least but too rapid movement leading to an actual heart attack. It is rare in the US for elevator users to be harmed but not that rare for maintinance workers to be harmed; it is actually a fairly dangerous profession.

IMO, it is actively harmful to blame the software industry as a whole for voting machines being horrible since however bad most software is there are parts of the industry that can produce software as reliable as bridges and elevators and those are the parts of the industry that should be used for voting machines even if the rest of the industry was quite a bit better. It is only for political reasons that voting machines are unreliable.

It happened 2 months ago, here in France. A kid died in the accident, and it was not a software problem. And there are tons of elevators out of order, on a daily basis, and more often for mechanical reasons than for software reasons (now obviously, the software part of an elevator is less complex than its mechanical part, but still).

I love how the bar gets lowered as people struggle to make software look reasonable. "Elevators out of order" is not "elevators crashing". Of course mechanical systems wear out and have to be repaired.

Elevators, bridges, airliners and other properly engineered systems, are incredibly safe and reliable. You have to go digging to find exceptional events that remotely compare to the daily chaos found in software systems. The point of my story is that elevators themselves (systems we barely think about on a daily basis) start to become chaotic and unreliable when software is introduced.

...which is not to say that it can't be fixed. My contention is that software engineering is possible, it just isn't fun or easy for inexperienced coders to do, and therefore not valued by the current software industry.

You were mentioning elevators crashing in the first place.

But anyway elevators are quite frequently out of order, and I don't know how often it's a software vs mechanical vs administrative (ie "security check") problem. I just know that, in all instances of elevator crashes I know of, the problem was a mechanical one, not a software one.

> ...which is not to say that it can't be fixed. My contention is that software engineering is possible, it just isn't fun or easy for inexperienced coders to do, and therefore not valued by the current software industry.

It's not that it's not fun, but it's incredibly expensive, and usually not worth the cost.

In this specific case, we have an essentially static system that's exposed to the public that you need to protect from an unknown number of attackers with substantially more resources than you do.

To use the analogy of the plane designer, it'd be equivalent to building a consumer airliner that can handle flying through a warzone.

It's because this field doesn't value experience, and instead values youth and rewriting things in Javascript.

It's maddening how preventable a lot of this stuff is, but you can't convince anyone to listen to you because rules and processes aren't fun.

Conversely, a lot of the incentives on these teams are perverse -- like the conversation in another thread about not being able to sell to stakeholders the idea of "remove junk" but being able to sell them the idea of "add AMP".

So even if you are the sort of software developer to consider the lifecycle and long-term utility of the products you produce -- good luck with that.

True. However, one thing I'll say about that: the older and more experienced you are, the easier it becomes to push back on stupid things.

Re: doesn't value experience, and instead values youth and rewriting things in Javascript.

JavaScript is so yesterday, PyChainGo is the newest and best. Get with the times!

Here's a list of commercial jet airliners: https://en.wikipedia.org/wiki/List_of_jet_airliners . About 68 have been developed, by less than 30 companies, over 70 years.

In the meantime, a junior programmer on my team just got an assignment (while I was on holiday) to add a feature to an old project she'd never worked on. The feature was described in three sentences, with a budget of "at most two days" as that is what the work was sold to the customer for.

I mean, it's rather hubristic to compare ourselves to those industries, we're closer to the handyman you hire to create a new door in some wall without telling him where exactly, all that matters is that it's done fast.

One major issue in electronic voting is the notion that it might enable an adversary to compromise a much larger number of votes than they would in a paper ballot system.

If every state contracts a handful (some may even contract a single one) of suppliers to crude the voting software, a bad actor that could compromise only one of those systems would have an enormous impact on an election. Contrast that with paper ballots, where an adversary would have to compromise dozens or hundreds of precincts, in-person, in order to have the same effect.

In terms of economics, having each precinct implement its own voting software (or contract uniquely) is not cost effective, nor would I trust small municipalities to be able to judge security.

It’s just too risky all around. Maybe one day when our software systems are better understood, or there are different security mechanisms, electronic voting might work. But not today.

Why is this different for software than for civil engineering? Fundamentally it’s not, except that people are willing to spend money on a new design for every bridge, and generally there is a collective awareness of threat models for bridges.

Reply on news.ycombinator.com