Sane people, I BEG you: Stop the software defined moronocalypse

Re: Might take a while

"If it's super complex, a la space shuttle, dev time is in decades and 1000s of folks check and recheck everything."

Except the O Rings.

That is not completely true.

In the first place, the whole reason why there were O-rings was due to politics. A certain Senator from Utah insisted that NASA place some work for the Shuttle project in Utah, or else he'd hold up funding. So they did. Originally, the solid rocket boosters were supposed to be built near the East Coast, or in Missouri, and would have been barged down to Florida, via the Mississippi if built in Missouri. This couldn't happen in Utah. The boosters would have to be transported by train. Problem: they couldn't be transported in one piece, as there were several curves on the rail lines (there be mountains in Utah, and more mountains between Utah and Florida) and the boosters were too long to negotiate the turns. This meant that they had to be cut in seven pieces, several of which were joined together at the factory so as to have the largest sections which could be moved by rail, which in turn required the O-rings to seal the remaining pieces.

In the second place, the O-rings worked (mostly) as long as they were used according to specs. They misbehaved only when used out of spec, such as when very cold. There were problems with the initial design, but a rebuild handled most of them. Except when the temperature dropped below freezing. The manufacturer's engineers on site told NASA before the launch that launching when that cold wasn't a good idea. NASA launched anyway.

In the third place, later investigation showed that the primary fault was in the attachments for the solid rocket boosters and the way they had been placed, which caused stress on the booster bodies. This, in turn, was not a problem except when it was cold... and the O-rings froze up and didn't do their job properly. If the attachments had been placed slightly differently, the flexing which allowed the spurts of hot gas (a.k.a burning rocket exhaust) to hit the external fuel tank (a.k.a big bomb full of liquid hydrogen and liquid oxygen) would not have happened. There was a redesign of the boosters which changed the attachment points. It should also be made clear that the spurts of hot gas burned away at least one attachment point, causing the booster to actually hit the external tank, not something that you want to happen while you're under acceleration.

Quote from the Wiki article:

The loss of Space Shuttle Challenger originated with a design flaw and system failure of one of its SRBs. The cause of the accident was found by the Rogers Commission to be a faulty design of the SRB joints compounded by unusually cold weather the morning of the flight.[11][12] The commission found that the large rubber "O-rings" in SRB joints were not effective at low temperatures like those of the January 1986 morning of the accident (36 °F (2.2 °C)). A cold-compromised joint in the right SRB failed at launch and eventually allowed hot gases from within that rocket booster to sear a hole into the adjacent main external fuel tank and also weaken the lower strut holding the SRB to the external tank. The leak in the SRB joint caused a catastrophic failure of the lower strut and partial detachment of the SRB, which led to a collision between the SRB and the external tank. With a disintegrating external tank and severely off-axis thrust from the right SRB, traveling at a speed of Mach 1.92 at 46,000 feet, the Space Shuttle stack disintegrated and was enveloped in an "explosive burn" (i.e. rapid deflagration) of the liquid propellants from the external tank.[13]

During the subsequent downtime, detailed structural analyses were performed on critical structural elements of the SRB. Analyses were primarily focused in areas where anomalies had been noted during postflight inspection of recovered hardware.

One of the areas was the attachment ring where the SRBs are connected to the external tank. Areas of distress were noted in some of the fasteners where the ring attaches to the SRB motor case. This situation was attributed to the high loads encountered during water impact. To correct the situation and ensure higher strength margins during ascent, the attach ring was redesigned to encircle the motor case completely (360 degrees). Previously, the attachment ring formed a 'C' shape and encircled the motor case just 270 degrees.

Additionally, special structural tests were performed on the aft skirt. During this test program, an anomaly occurred in a critical weld between the hold-down post and skin of the skirt. A redesign was implemented to add reinforcement brackets and fittings in the aft ring of the skirt.

These two modifications added approximately 450 lb (200 kg) to the weight of each SRB. The result is called a "Redesigned Solid Rocket Motor" (RSRM).

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

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

Re: Might take a while

First, let me start out by saying that I agree we do need to learn to be better and safer as devs. And, yes, engineering has some things to teach us, because it is a technical discipline in problem-solving like ours. On that we don't disagree.

However, I think we could also learn from the medical profession in how to problem-solve in conditions of uncertainty, complex interactions, evolving threats and emerging base of knowledge. Sounds less like a fit than engineering so, just maybe we wouldn't be gulled into thinking that it was THE answer.

>Each bridge (or ship) is its own development

Well, maybe, but they generally do the same thing, don't they and we've been building bridges for thousands of years. 20 years ago there was no javascript or generalized public-facing access points, which is what websites are. 30 years back, nearly no networks to attack via.

A bridge engineer will design many bridges in her life, but she won't necessarily switch to building airports. Yet, devs are mostly expected to switch subject matter and languages quite quickly.

>We most certainly do and they are getting better.

I took a quick looksee at wikipedia for formal methods, just to make sure I hadn't missed any new development about those and I found, as expected, that they are very costly and very limited in use. Hardly a solution for the average dev, is it? A bit like arguing that the design technique, funding and sheer expertise applied to building the Burj Khalifa are available to your local house builder.

They could be, if cost was no constraint.

On the other hand, the Reg has had several recent articles about applying automated analysis of software behavior in order to highlight possible security weak points. Now, the prospect of getting that to work gets me all hot and bothered, not your formal methods, sorry.

>I'm a developer, not a mathematician

Before becoming a dev I graduated with a BS in Electrical Engineering. What you don't get is how intrinsic math is to engineering. You start out building a solid foundation of math and then you learn how to apply the equations relevant to your particular field. Engineering is a combination of applied mathematics and then creativity/skill in the field, but math is foundational to any engineering field and the formalism that the mathematical underpinning allows is what gives engineering the qualities which the OP suggests we borrow from civil engineering.

There is no such underpinning mathematical foundation in general software.

So, no, we agree to disagree on that too.

Also, to be fair, many of the big hacks wouldn't be helped just by better coding. Heartbleed? Yes. Apples Yosemite root hack? Definitely.

Bradley Manning, copying hundreds of MB for classified docs? The system was working as designed. OPM hack, 22M profiles hacked? How many IT subsystems in the US Federal needed to trawl through 22M records? Shouldn't access on that scale have raised alarm bells? Shouldn't those records have been guarded like Fort Knox? Ditto Targets 40m cc hacks. What about Ashley Madison? Why did those morons really need to have the CC info on such a lucrative and publicity-shy bunch of users? What about all security issues due to compromised and reused passwords?

Better coders, yes. But how about deploying systems with better heuristics about normal vs anomalous use? Rate limiting access to sensitive data? Watch-dogging the networks to see when data flow from particular sensitive nodes are unexpectedly high? Most of all, how about borrowing, from the military, not the engineers, the notion of need-to-know. As in, limit which systems can access which data, at what rate. And, even more so, limit the data that your own organization retains in the first place. If you don't have some info, then getting hacked will not have compromised that info. The marketing gals will hate you for it, but it should be our first line of defense.

>Friends don't let friends code in flash

Extremely good point, but that is not a dev call. That is a system architect call, and to be frank, if all IT security weaknesses had as simple a solution as not using obviously unfit tools like Flash, then we wouldn't be in the shit storm we are in.

Re: Might take a while

Exactly, Vic. Well said.

Re: Might take a while

It was traditionally the architect. I think that would translate to senior management.

Re: Might take a while

The project managers. It is their job to get the complex organized. If it fails, it is their fault. They failed in management. Project management is stressful - on account of the unknowns that inevitably occur, on account of the slippage in time that inevitably occurs, and so on.

If the requirements or resources are insufficient, they need to say so at the earliest possible time that the project can not be met with the given requirements and resources. Devs are resources. If they are working sloppily or not to spec, they are a poor resource and should be given a task force on website usability.