←back to thread

669 points danso | 5 comments | | HN request time: 0.631s | source
Show context
_bxg1 ◴[] No.23260967[source]
This is the latest in a string of incidents where critical software systems, facing new pressure due to the pandemic, are catastrophically failing their users. I think what's happened in the past is that most public-facing software systems either a) were not really critical (because people had the alternative of doing things in-person), or b) (as in the case of all the ancient COBOL systems underpinning the US gov) had been made reliable over the years through sheer brute force as opposed to principled engineering. But in the latter case, as we saw with New Jersey's unemployment system, that "reliability" was fragile and contingent on the current state of affairs, and had no hope of withstanding a sudden shift in usage patterns.

Now we have various organizations - governmental and otherwise - hastily setting up online versions of essential services and it seems like every single one of them breaks on arrival.

We need some sort of standard for software engineering quality. I don't think this is an academic question anymore. Real people's lives are being impacted every day now by shoddy software, and with the current crisis they often have no alternative. Software that you or I could probably have executed better, but that the people who were hired to do it either a) couldn't, or b) didn't bother. It's nearly impossible for non-technical decision makers in these orgs to evaluate the quality of the systems they've hired people to build. We need quality assurance at an institutional level.

If not governmental, maybe an organization around this could be made by developers themselves. Not the "certified for $technology" certifications we have now, but a certification of fundamental software engineering skills and principles. A certification you can lose if you do something colossally irresponsible. At the end of the day, this dilution of quality is having a negative impact on our job field, so it concerns all of us. It leads to technical debt, micro-management, excessively rigid deadlines and requirements, which we all have to deal with. All of these are either symptoms of or coping mechanisms for management's inability to evaluate engineering quality.

replies(15): >>23261019 #>>23261187 #>>23261210 #>>23261239 #>>23261289 #>>23261414 #>>23261666 #>>23261696 #>>23261835 #>>23261851 #>>23261876 #>>23262059 #>>23262102 #>>23262525 #>>23263763 #
bobthepanda ◴[] No.23261289[source]
> We need some sort of standard for software engineering quality. I don't think this is an academic question anymore. Real people's lives are being impacted every day now by shoddy software, and with the current crisis they often have no alternative. Software that you or I could probably have executed better, but that the people who were hired to do it either a) couldn't, or b) didn't bother. It's nearly impossible for non-technical decision makers in these orgs to evaluate the quality of the systems they've hired people to build. We need quality assurance at an institutional level.

Even if you were to put this in place today (which I don't necessarily agree with) you would still need bean-counters to sign off on paying for replacement services for their sweat, tears and duct tape solution. A good half of the electorate and the politicians, give or take, whip up into a frenzy if a bureaucrat so much as looks at a dollar bill the wrong way, so I doubt this would gain any traction.

replies(1): >>23261333 #
1. _bxg1 ◴[] No.23261333[source]
New sweat, tears and duct tape solutions are being created every day. Let's start by focusing on the ones coming down the pipe.
replies(2): >>23261968 #>>23264149 #
2. macintux ◴[] No.23261968[source]
Which would still face the same problem: the government would rather pay multiple times for crappy software at a lower price than one big bill for quality software the first time.
replies(2): >>23262148 #>>23264316 #
3. ashtonkem ◴[] No.23262148[source]
That's not a problem unique to governments, although the consequences in that realm tend to be worse.
4. bobthepanda ◴[] No.23264149[source]
What matters to the bean counters is if it can be done without expensing something new, everything else be damned. Unless you can get a clear, popular government mandate to spend money to make things more efficient, this is not a palatable solution.

Given how large refactors tend to go in general, this also doesn't necessarily lead to good outcomes; even with a relatively technocratic administration led by Mike Bloomberg (relative to comparable mayors, at least), upgrading NYC's 911 system massively spun out of control: https://www.nydailynews.com/new-york/911-overhaul-2b-disaste...

5. jimbokun ◴[] No.23264316[source]
Or you can pay one big bill and still get crappy software.

It's difficult to evaluate the quality of software development contractors.