This makes me wonder how long it would take for a competent technical leader to course-correct the culture and product issues that have crept in at Boeing. It seems to me it would be on the order of years to get their house in order to get quality to where it should have been.
At this point it would be easier to start a new company and import the positive things from Boeing. They've lost their "engineering first" mentality and that's not something that is easy to get back, and they may not be able to handle the financial losses involved in doing so after running as "money first" for so long.
From what I've heard, the recent CEO who was forced to step down was the competent technical leader that was working on fixing the problems at Boeing. He just didn't have time to do it.
> competent technical leader to course-correct the culture and product issues that have crept in at Boeing.
This issue looks to be a pretty run-of-the-mill bug in their software. It's likewise scoped down pretty far--there only exist a few runways (in US, Colombia, and Guayana) that make this relevant. ADs like this come out all the time.
Not blaming this commenter specifically, but this pervasive callous attitude of over-focusing on narrow metrics of importance seems to be why our general experience with software is so... shitty.
The problem with such “partial” functionality is that it breaks composition. When you start building systems with a dozen modules, each with a couple of edge cases like this, the probability of something failing becomes high, and makes the final result/experience very crappy. Imagine if you had a sweater you couldn’t wear on Tuesdays!
For those who don’t get it, it’s not just about how often this “bug” affects the system (let alone the fact that it is quite severe). It indicates an utter lack of competence towards developing safety critical systems... like, how can one be writing navigation code and NOT know this?
That this could be considered a run-of-the-mill software bug means that we have set our standards too low.
I get the gist of what you are saying about it being par for the course, but can you explain why a heading of 270 (West if 0 is North)would affect air worthiness? Is it something to due with true North vs. magnetic north deviations? Grasping here. I am truly curious about this one. Thanks!
F-22 had similar weird bug. Instead of degrees it was dates.
In 2007 squadron (12) of F-22's were flying from Hawaii to Japan. When they crossed when they crossed international date line every plane had systems crash. They lost communication-, fuel-, and navigation subsystems and restart did not solve the problem. Apparently only basic aviation systems worked. They could still fly.
They would have been completely lost, but luckily tanker escorting them was still nearby. They were able to follow it back to the base.
That does bring up an interesting point. There's only so many airports in the world (especially ones that can support a 737). You'd think that'd be easy to exhaustively test if you wanted to.
Would a viable workaround be to tell it the heading is 269 or 271? You’d land at a slight angle which would have you moving about 17 m toward an edge of the runway for every km down the runway you go. That seems mild enough for the pilots to correct once they are on the ground.
FTA: "All six display units (DUs) blanked with a selected instrument approach to a runway with a 270-degree true heading, and all six DUs stayed blank until a different runway was selected."
The bigger problem is anyone using trigonometry (instead of vector methods) in practical geometry code, where not absolutely necessary.
If you go poking around geometric code (cartography, computational geometry, physics modeling, graphics, ...) and hunt for places where trigonometry is used, you’ll find lots of errors where the programmer didn’t consider the behavior in every edge case. The vector alternatives are simpler, more efficient, more numerically stable, and a lot easier to reason about.
Rust doesn't by default, though you could certainly make a wrapper type that does. You could do the same in any language that has algebraic data types (rust enum's), or another sensible way of forcing you to check certain kinds of errors.
It does. There are types in the standard library for non-zero numbers[1]. While it would involve writing a wrapper, Rust does provide for customizing the behavior of operators[2]. The example implementation for Div (the "/" operator) even shows how to make a type that panics when trying to divide by zero. One could also return a Result so that trying to divide by zero can fail gracefully.
I'll have to experiment with implementing that as well as how Rust divides by zero. Thanks for sharing.
My probably wrong understanding is that the philosophy behind Rust is that code without IO/unsafe shall not panic. It might provide useless results but it won't panic. But dividing an integer by zero causes a panic (if I recall).
Edit: derp. Of course they can panic. You really can't guard against overflow or OOM and such. gpm helped correct my thinking: it's not about avoiding panics, it's about avoiding undefined behaviour, forcing you to define all possible branching paths.
Readit News
Undefined. The problem was never a lack of technical proficiency, the problem is the culture.
This issue looks to be a pretty run-of-the-mill bug in their software. It's likewise scoped down pretty far--there only exist a few runways (in US, Colombia, and Guayana) that make this relevant. ADs like this come out all the time.
The problem with such “partial” functionality is that it breaks composition. When you start building systems with a dozen modules, each with a couple of edge cases like this, the probability of something failing becomes high, and makes the final result/experience very crappy. Imagine if you had a sweater you couldn’t wear on Tuesdays!
For those who don’t get it, it’s not just about how often this “bug” affects the system (let alone the fact that it is quite severe). It indicates an utter lack of competence towards developing safety critical systems... like, how can one be writing navigation code and NOT know this?
That this could be considered a run-of-the-mill software bug means that we have set our standards too low.
In 2007 squadron (12) of F-22's were flying from Hawaii to Japan. When they crossed when they crossed international date line every plane had systems crash. They lost communication-, fuel-, and navigation subsystems and restart did not solve the problem. Apparently only basic aviation systems worked. They could still fly.
They would have been completely lost, but luckily tanker escorting them was still nearby. They were able to follow it back to the base.
Holy f-cking f-ck.
And if not the compiler, are there popular static analyzers for any languages that do so?
If you go poking around geometric code (cartography, computational geometry, physics modeling, graphics, ...) and hunt for places where trigonometry is used, you’ll find lots of errors where the programmer didn’t consider the behavior in every edge case. The vector alternatives are simpler, more efficient, more numerically stable, and a lot easier to reason about.
Deleted Comment
1. https://doc.rust-lang.org/std/num/struct.NonZeroI32.html
2. https://doc.rust-lang.org/std/ops/trait.Div.html
My probably wrong understanding is that the philosophy behind Rust is that code without IO/unsafe shall not panic. It might provide useless results but it won't panic. But dividing an integer by zero causes a panic (if I recall).
Edit: derp. Of course they can panic. You really can't guard against overflow or OOM and such. gpm helped correct my thinking: it's not about avoiding panics, it's about avoiding undefined behaviour, forcing you to define all possible branching paths.
Deleted Comment