Ethiopian Airlines 737 MAX Investigation Preliminary Report - <AUTHOR> http://www.ecaa.gov.et/documents/20435/0/Preliminary+Report+B737-800MAX+%2C%28ET-AVJ%29.pdf/4c65422d-5e4f-4689-9c58-d7af1ee17f3e <comment><USER2> Indeed looks like they did disable MCAS using the stabilizer trim cutout switches, but the aircraft was trimmed nose down when they did so. Aerodynamic loading prevented manual trimming using the trim wheels. They eventually turned electric trim back on, as they didn't really have any other options, but didn't trim back enough, and left it turned on. At this point the right airspeed indicator (which should be more reliable) reads 365 knots. VMO is 340, so they're already in big trouble. 5 seconds later, MCAS kicked back in, and then it was all over. Very sad.

<comment><USER3> > Aerodynamic loading prevented manual trimming using the trim wheels.

Are the trim wheels mechanically connected to the trim mechanism in the back? Is there no way to trim the horizontal stabilizer electrically without also enabling MCAS? What would happen if the pilots continually pressed the trim up switch on the yoke? That should've prevented MCAS from activating, right?

I thought Boeing airplanes were built such that "the pilot is always in control". That doesn't seem to be the case anymore, if by cutting the power to certain subsystems you can't control the airplane anymore.

<comment><USER4> I thought all jets had to be capable of performing non powered glides (as in no electrical power, not just engine power).

I guess that's no longer a requirement.

<comment><USER5> Being capable of performing a glide without electricity does not necessarily imply that a no-power glide can safely be entered from extreme conditions like diving too fast with trim set to insane.

<comment><USER6> Why is it possible to set the trim to insane? Is there a legitimate scenario where that would be used?

<comment><USER7> If the AoA was truly way too high then insane trim would be required to correct that. MCAS and similar systems came about in response to AF 447 where the pilots entered a high AoA situation and stalled the plane into the Atlantic.

<comment><USER8> Is it necessarily true that you have to use the stabilizer for MCAS? Would implementing a stick pusher instead fail to avoid some stalls?

<comment><USER9> It's true in the case of the 737 MAX where the pitch-up moment caused by the engines exceeds the elevator authority in a low-speed, high-thrust situation if the pitch trim is also set too high.

MCAS will evidently work with less maximum nose-down trim than the current version has, as the proposed update places a limit on it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> > The crew performed runaway stabilizer checklist and put the stab trim cutout > switch to cutout position and confirmed that the manual trim operation was > not working.

This is very damning to Boeing. It's precisely the procedure they prescribed and intended to mitigate possible MCAS caused trim runaway. In light of the fact that they put this in place as a justification for moving the engines forward without reclassifying the plane, I don't see how they can get around fault here.

What a tragedy.

I can't imagine the emotion those pilots must have felt after attempting to do exactly what they were told to do to keep the aircraft in the air, only to have the nose lurch back downwards. Godspeed, gentlemen. It wasn't your fault.

<comment><USER11> It does not appear to be "precisely" the procedure, in that sufficient nose up trim was not selected by the yoke manual trim switch prior to pulling the trim cutouts. And then they did not work the mechanical trim wheel hard enough to reset the residual nose down trim.

And, the crew left the power setting at climb throughout almost the entire sequence, so they oversped the airframe.

And, when they (against procedure) (apparently) turned the electric trim system back on, they did not use the yoke manual trim switch to fix the nose down trim problem -- which is a big mystery.

The MCAS design inhibits its FCC trim down output when manual trim is utilized. So, if they had just continuously pushed the nose up manual trim switch on the yoke until they got the trim to neutral, then pulled the cutout (either the first time or second time), the accident could have been avoided.

History shows this is not a good human factors design on the part of Boeing, but the crew does not look good, either, IMO.

<comment><USER8> > sufficient nose up trim was not selected by the yoke manual trim switch > prior to pulling the trim cutouts

The EAD/service bulletin doesn't talk about sufficient nose up trim or caution against performing the cutout with even a slight mistrim.

> And then they did not work the mechanical trim wheel hard enough to reset > the residual nose down trim.

It's possible that aerodynamic load (of the stabilizer opposing the elevator) made it physically impossible to manually trim given any mistrim at the time the cutout happened, given the airspeed they had. And, the captain is pulling back on the yoke as hard as he can, so he's unavailable to let go of it and grab a trim wheel instead without immediately losing altitude.

> And, when they (against procedure) (apparently) turned the electric trim > system back on

It seems sensible to assume -- and the report states -- that they did this because they found that manual trim was impossible in these circumstances.

<comment><USER12> > It's possible that aerodynamic load (of the stabilizer opposing the > elevator) made it physically impossible to manually trim given any mistrim > at the time the cutout happened, given the airspeed they had.

Its been noted in previous discussions that while it would be difficult, the load can be overcome if both pilots were to operate the manual trim wheel at the same time.

Not that its a good situation to be in.

<comment><USER8> > Its been noted in previous discussions that while it would be difficult, the > load can be overcome if both pilots were to operate the manual trim wheel at > the same time.

I haven't seen that noted anywhere, and have seen it theorized as impossible without motor assist, given their airspeed and with the elevator opposing. Got a link?

<comment><USER13> _Manual Stabilizer Trim_

Excessive airloads on the stabilizer may require effort by both pilots to correct the mis-trim. In extreme cases it may be necessary to aerodynamically relieve the airloads to allow manual trimming. Accelerate or decelerate towards the in-trim speed while attempting to trim manually.

[https://www.pilot18.com/wp- content/uploads/2017/01/B737NG_FC...](https://www.pilot18.com/wp- content/uploads/2017/01/B737NG_FCTM_31-10-05.pdf) page 312 (8.16)

<comment><USER8> To be clear, that's a link that agrees with me that it can be impossible, not a link that says they just needed to work harder.

It's also from a 20 year-old manual, and isn't present on newer manuals, and pilots haven't trained on it in decades. Not appropriate to expect pilots to know, and possibly not helpful here: the pilots were low altitude, so allowing the nose to drop even further (to relieve aerodynamic load) may have been deadly too.

<comment><USER13> [https://www.satcom.guru/2019/04/stabilizer-trim-loads-and- ra...](https://www.satcom.guru/2019/04/stabilizer-trim-loads-and-range.html) does a pretty good job of summarizing it I think. It sounds incredibly difficult to do.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> The design of this system, from what I've heard so far sounds _insane_.

For some background, systems intended to automatically override pilot input upon detecting an impending stall have been used on large, complex aircraft for a long time. The most common mechanism is a stick pusher, which mechanically pushes forward on the stick to mimic what a pilot _should_ do about an impending stall. The force of a typical stick pusher is low enough that a pilot can overcome it with arm strength.

A stick pusher, or a pilot pushing forward on the stick is not enough for the aerodynamics of the 737 MAX in certain circumstances. The position of the engines means the thrust tends to push the nose up, and at low speed, the elevator controlled by the stick alone is not enough to push the nose down when nearing a stall. Instead, the trim must be used, which moves the whole horizontal stabilizer rather than just the elevator. That's not part of the procedure on most aircraft, including other 737s, so regulators would not allow pilots rated for 737s to easily transfer their rating to the new aircraft, if they were willing to certify such an aircraft at all.

MCAS is the solution to this problem. It automatically uses the trim to force the nose down with greater authority than the elevator alone could provide. While the concept is sound, the implementation strikes me as reckless.

First, the system uses only one of the two angle of attack sensors to determine that the aircraft is nearing a stall. Such sensors have a fairly high rate of failure relative to the safe operation of a commercial aircraft. As far as I can tell, causing the system to use both sensors is a _software_ change and all models of the aircraft had the required hardware. I can't imagine a good reason the system was designed this way, especially since Boeing has included MCAS on a previous aircraft, the tanker version of the 767, and it did use two sensors in that application.

Second, activating the system automatically, and allowing it to contradict the pilot's attempt to pitch up using the elevator seems like a mistake. While stalls are almost always the result of pilot error, I'm inclined to think automated systems should let humans have the last word. A better design might have been to automatically trim nose-down in response to full forward pressure on the stick at low speed. That could be in combination with a stick pusher providing full forward pressure on the stick when an impending stall is detected _in the absence of pilot input to the contrary_.

<comment><USER14> A compounding problem is, if the MCAS system is disable, now the flight characteristics are completely changed. Without additional training, there's no way for the pilots to know they have to trim down.

<comment><USER9> There's no way for pilots to know they have to trim down under what conditions?

<comment><USER14> During otherwise normal flight conditions, the nose might unexpectedly pitch up. MCAS is designed to prevent that when AoA > somevalue to prevent stalling.

<comment><USER9> During normal flight conditions, the nose does not pitch up beyond the pilot's ability to control with the elevator, and the pilot doesn't fly especially close to the critical angle of attack.

MCAS is for an unusual combination of conditions where both elevator and trim might be needed to reduce the angle of attack. An example would be if the pilot set a fairly high nose-up trim to maintain the slow speed of final approach, then decided to go around (abort the landing), applied full thrust, and fully raised the flaps too early.

A pilot would definitely know that using trim is an option if the elevator was not producing enough nose-down pitch, but a pilot who has put the aircraft into the situation where a stall is imminent during a passenger flight has already made a series of errors.

<comment><USER14> > An example would be if the pilot set a fairly high nose-up trim to maintain > the slow speed of final approach, then decided to go around (abort the > landing), applied full thrust, and fully raised the flaps too early.

This scenario seems it would apply to previous generation 737s as well. But for some reason, MCAS was required for the MAX 800.

Everything I have read so far indicates the MAX 800 has some 'pitch up on it's own' type problem that can lead to a stall. So while I'm sure it's possible to crash the plane in a variety of ways, none of that has to do with MCAS.

<comment><USER9> All 737s have a nose-up pitch moment from the thrust of the engines because they're hanging under the wings. The engines of the MAX are more powerful, and positioned differently resulting in a stronger nose-up moment.

The elevator is not enough to overcome the nose-up pitching moment of the MAX under certain conditions, but the trim is.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> This puts the nail in the coffin of a quick software fix getting the max back in the air anytime soon. To have any credibility the FAA is going to have to recertify the entire flight control system with all failure modes considered. And no scout's honor with Boeing this time.

</comment><comment><USER16> This isn't only MCAS issue anymore... If there are issues with manually rectifying trim after it went haywire because of any reason, that might be a problem. Interesting to find out was that an issue with older 737 models, just without severe runaway trim events.

<comment><USER17> > If there are issues with manually rectifying trim after it went haywire > because of any reason, that might be a problem.

It's not so much a "problem" as it is "physics". If the stabilizers are forcing the nose down, and the pilot pulls back on the stick (engaging the elevators) to pull the nose up, the forces exerted on the stabilizer are such that, in extreme cases, human force is insufficient to move the manual wheel.

This is extremely (EDIT: No longer) well documented by Boeing going back decades, and it presents solutions of either: 1) reengaging the electronic stabilizer trim and trimming electronically back to a point where the forces are manageable, then cutting electronic trim again, or 2) relaxing the stick, letting the nose go the way the stabilizers want it to, which slackens the force, and makes cranking the wheel manually doable. Great if you're stabilizers are trimmed severely nose down at a height of 40,000 feet; less great at a height of 1,000 feet. (EDITED TO ADD: Apparently this information & procedure was removed from Boeing's manuals after the 1980s, and pilots no longer train on it, as the issues that led to its necessity were thought solved. The MCAS apparently has reintroduced the need for them.).

This is _compounded_ by a new change in the 737-MAX: in prior 737 series aircraft, there are two stab trim cutout switches: one to cut the autopilot's ability to command the stabilizer trim, the other to cut electronic power to the stabilizer trim adjustment entirely, so you could stop the autopilot from changing the trim but still retain electronic control and not need to worry about the manual crank forces. The two switches are MAIN ELEC and AUTO PILOT.

In the MAX, this changed, and it's now an all or nothing setup: you have to kill electronic power to kill autopilot commands to the stabilizer. The two switches are now PRI and B/U. Both must be cut out to stop any stabilizer runaway, including MCAS runaway.

This all seems to add up to Boeing's narrative of "The MCAS is safe, pilots just need to know to hit the stab trim cutout" being grossly insufficient. They must cut it at a moment where the stabilizer isn't grossly mistrimmed with respect to level flight, OR they may well need to re-engage it _and race the MCAS_ to get into a close-to-proper trim setup prior to cutting out the stabtrim and assuming manual trim control.

<comment><USER10> > They must cut it at a moment where the stabilizer isn't grossly mistrimmed > with respect to level flight, OR they may well need to re-engage it and race > the MCAS to get into a close-to-proper trim setup prior to cutting out the > stabtrim and assuming manual trim control.

All while keeping the plane in the air, reading the manual, and attempting not to lose composure knowing that the same thing has happened to another flight that lost all hands.

I'm trying very hard to look at this objectively, but this is an extremely bad look for Boeing.

<comment><USER18> > > They must cut it at a moment where the stabilizer isn't grossly mistrimmed > with respect to level flight, OR they may well need to re-engage it and race > the MCAS to get into a close-to-proper trim setup prior to cutting out the > stabtrim and assuming manual trim control.

> All while keeping the plane in the air, reading the manual, and attempting > not to lose composure knowing that the same thing has happened to another > flight that lost all hands.

Additionally an angle of attack (AOA) sensor failure also triggers an unreliable airspeed warning so the pilots no longer trust their airspeed sensors or their AOA sensors while trying to judge pitch and speed. If they go too fast the control forces overpower them, if they go too slow they are more likely to stall.

I don't think Boeing gamed out or tested in a simulator the human factors involved in an AOA failure at takeoff, particularly for pilots who - like the Lion Air pilots - are entirely ignorant of MCASes existence.

<comment><USER10> I don't remember where I read it, but my understanding is that the MAX simulator does NOT simulate MCAS behavior.

EDIT: Found it: [https://www.reuters.com/article/us-ethiopia-airplane- simulat...](https://www.reuters.com/article/us-ethiopia-airplane-simulator- exclusive/ethiopia-crash-captain-did-not-train-on-airlines-max-simulator- source-idUSKCN1R20WD)

<comment><USER18> Thank you for that. Putting hundreds of aircraft into service before the simulators were available to airline pilots looks rather bad in hindsight.

I would hope that Boeing internally had simulators for the MAX while they were testing it - along with a borrowed supply of pilots who were competent but had no inside information. Even if they didn't, a pencil and paper exercise might have been useful:

1\. AOA sensor fails at takeoff (A), the pilots receive an unreliable airspeed warning and the stick shaker activates. The pilots now mistrust their sensors and want to keep their speed up and the nose down.

2\. At about 1000 feet above ground the pilots level the aircraft, raise the flaps and start the unreliable airspeed checklist. MCAS starts trimming intermittently.

3\. The pilot flying is having to pull further back on the stick and trim correctively while the crew work through their checklist. At this point the crew need to avoid any over-focus, task saturation or over-stimulus from the many warnings and indicators and ask themselves why the aircraft is trimming the way it is. They have a fairly narrow window of time in which to do this and then disable the trimming with the plane in a well trimmed state.

(A) That this happened twice in relatively quick succession might be due to a common problem. Even if such a problem is found and fixed the AOA vanes and pitot tubes are delicate sensors sticking out of the nose of the aircraft; the system should be robust to failures in these sensors.

</comment></comment></comment></comment></comment></comment><comment><USER19> It appears that Boeing's directive was simply wrong, and doomed them. The right response to faulty MCAS is not to do a stab trim cutout and then manually retrim, but to first use the manual electric trim switches to fix the trim and then immediately do a stab trim cutout. This is mentioned at the end of the directive, but reads more like an afterthought when it should be the standard procedure.

<comment><USER20> In my opinion the pilots here have attempted to follow that checklist as well as could be expected (bearing in mind that their lives depended on it). Having to trim to neutral before disengaging the trim would have contradicted the normal trim runaway checklist.

We're now talking about pilots having to have abnormal levels of skill and possibly even strength to fly this aircraft.

That's an untenable state of affairs. Boeing have really screwed this one up.

</comment></comment><comment><USER21> _> Both engines were found buried in the ground at a depth of approximately 10 meters._

My God.

<comment><USER22> fly into the ground at 40 degrees doing 600mph will do that.

</comment></comment><comment> dao- I'm starting to think that disabling MCAS isn't even a sane option because then the pilots are exposed to unexpected aerodynamic characteristics due to the plane's weird design. Does this make sense?

<comment><USER14> Many people have this opinion. You can't both require MCAS and be okay with disabling it at the most critical portion of a flight where the system is needed most.

<comment><USER23> _> You can't both require MCAS and be okay with disabling it at the most critical portion of a flight where the system is needed most._

If MCAS activates when it isn't supposed to, which is what happened here, disabling it is what you want to do--to stop it from doing an incorrect thing. The plane was not in a situation where MCAS was needed; it was perfectly flyable without MCAS in the flight regime it was in.

The problem is that, _if_ you disable MCAS (which requires disabling the entire electric stability trim system) without first using the electric trim system to get back to something close to neutral trim, you will be stuck with a lot of nose down trim that you can't remove fast enough with the manual trim wheel. It looks like that's the situation this flight got into.

But if you first use the electrim trim system to get back to something close to neutral trim, and then, before MCAS has a change to mess it up again, disable the entire electric stability trim system, you're ok. How do we know? Because that's what the first Lion Air flight (the one the day before the one the crashed) did, because an off duty pilot that was riding in the jump seat figured out what was happening and how to deal with it and told the pilots what to do.

<comment><USER14> > The plane was not in a situation where MCAS was needed;

As far as I can tell, there is no takeoff (pitch up) situation where MCAS is _not_ needed on the MAX 800. It's required for safe operation of the plane, otherwise the nose might pitch up unexpectedly into a stall.

As I said, the system can't both "be required for safe operation of the plane" and "it's safe to disable MCAS while it's malfunctioning during takeoff." You have to pick one.

<comment><USER23> _> As far as I can tell, there is no takeoff (pitch up) situation where MCAS is not needed on the MAX 800._

Reference, please? I have not seen anything that says MCAS is required for safe operation at a normal angle of attack for takeoff and climb to altitude. Note that the key parameter is angle of attack, not pitch angle; if the plane is climbing the angle of attack is lower than the pitch angle, because the plane is climbing so the relative wind is coming from somewhat above the horizontal direction.

</comment></comment></comment></comment></comment><comment><USER24> I usually enjoy HN discussions, but this is a pitiful and sad thread. I couldn't be bothered trawling past the responses to the top comment with back seat drivers, and "ooh but I read the 737's flight manual, they fucked up".

Likely 99% of the commentariate here are neither 737 Max pilots, let alone even licensed to fly commercial passenger jets, or even have a pilots license. And no, as much as I love the guy, watching Mentour Pilot does not make you an expert. They have fuck all knowledge about, or even experience, about the sudden cockpit workload that was imposed on these pilots until the point of hull loss. Have some respect. Oh, and you know what, this was Ethiopia's national carrier, I expect these flyers were at the top of their profession and as good a pilot as any other national carrier,

<comment><USER25> Can't upvote enough. As someone who actually does fly airplanes for a living it's disturbing to me the amount of 'expert' arm chair quarterbacks that have come out on HN in the wake of these two incidents. Immediately after the Ethiopian crash there were 200+ comment threads every few hours full of experts speculating about all the things that went wrong. People who were flat out wrong could not be told otherwise. I had to stop even engaging.

<comment><USER24> Thanks for the supportive comment. I thought I was going to get a polite but firm message from dang asking me not to drink-and-hackernews :)

</comment></comment></comment><comment><USER21> Am I mistaken or is there a missing item in the chronology where the pilots reactivated the electric stabilizer trim?

The timeline mentions stab trim being switched to cutout, and if you look at the FDR graphs there's a (relatively) long period of more-or-less stable trim after that. But then there's an automatic trim down, which is only possible if the electric stab trim is switched back on, and there's no mention of that.

I also can't help but wonder if exceeding Vmo was a factor.

(I don't mean to sound as though I'm trying to assign any blame here. Obviously this was a confluence of problems, the most significant of which is the control system reacting to an erroneous 75° (!) AOA indication.)

<comment><USER26> I find it amazing that there is no mention in the report of this fact. The investigators obviously know that they turned the cutout switches back to normal mode. Assuming there really was no mention of it on the CVR strongly suggests that it was the very inexperienced first officer who did this (the switches are on his side) without getting concurrence from the captain.

If you carefully study the graphs in the report, the plane was really not in bad shape up until this point. They were 7000 feet above ground and climbing. They were going too fast, but again, this is the fault of the crew. If they would have not flipped the cutout switch and taken stock in the situation and backed the throttles down, it is quite possible this flight would have ended very differently.

<comment><USER27> There are a lot of well-taken comments in this thread. However, in reading the Lion crash report and this one, it strikes me that there is a fundamental difference in the crashes. In this case, it appears that the pilots had very little knowledge about the reasons why the anti-stall system was implemented. And their combined flight time on the MAX is absolutely pitiful. In short, normally one thinks of a stall as a low speed event. In this case, by switching to manual with an improperly trimmed plane, it began a process which could be magnified by an accelerated turn (one of the reasons the MACS exists in the first place.) They began executing a rapid 180 degree turn at >300 knots, which is shown on the attitude graph, headed back to the airport. With a heavily loaded plane, is there any reason to doubt this wouldn't induce a high speed stall? The plane became so unstable, as it was outside of its operating envelope, they could not manually trim it. When they used electric trim it turned the anti-stall system back on, and it nose-dived the plane. The Boeing manual and/or directive says once you turn it off, it stays off. If they were unable to manually trim, is it really much of a surprise given their airspeed and rapid turn? So you ultimately see an electric trim which did little to help them, and assured anti-stall would kick in again. The report shows that neither of the pilots had signifcant experience in the MAX. The CVR is replete with ignored overspeed warnings, and stall warnings. An experienced pilot would know the danger is not a low speed stall, but a high speed stall accelerated by a mismanaged turn. By the time they tried to electrically trim it, it was over. Many planes are not aerodynamically stable without computer assistance. This crash is far different from the Lion crash. And I have not seen a single news outlet state the conclusions (or lack thereof) in the report accurately.

</comment></comment></comment><comment><USER28> >The left Indicated Airspeed increased, eventually reaching approximately 458 kts and the right Indicated Airspeed reached 500 kts at the end of the recording. The last recorded pressure altitude was 5,419 ft on the left and 8,399 ft on the right.

How can the sensors record such different readings?

<comment><USER18> The reading from the pitot tubes (pressure sensors) for a particular airspeed varies with the sensors angle to the airstream so the airspeed value is adjusted based on the angle of attack (AoA). If the AoA sensor is on the fritz on one side the airspeed reading for that side changes.

For redundancy, each pilot receives separate instrument readings from independent sensors. When the airspeed readings disagree a warning is activated and the pilots are expected to follow a prescribed and memorized procedure. The warning that the AoA sensors disagree was a paid option before this crash and the Lion Air crash.

<comment><USER29> While the changes in the right pressure altitude indicator track those of the radar altimeter reading, the left falls below it -- except, in the last 15 seconds, there are blips where the left pressure altitude jumps to match the right one. These correspond to the the times when the errant left AofA indication briefly matches that from the (apparently working) right AofA vane.

The airspeed discrepancy has the same pattern: the left is reading low and also showing blips, where it equals the right reading, that also correspond to when the AofA indicators match.

All this would be consistent with the left AofA reading being used to correct the left static pressure reading by raising it at high angles of attack, and vice-versa for the right AofA vane and static port (this assumes there is a right static port used by the right pressure-driven instruments, an a left port for the left ones.)

</comment></comment></comment><comment><USER30> Do we know of any documented situations in which MCAS actually did it's job correctly, that is, preventing a stall from too large AoA?

<comment><USER31> Preventing a stall is _not_ what the job of MCAS is.

(edit: clearer language)

<comment><USER8> This language is not clear, at least to me. MCAS is absolutely an anti-stall system. There's some correlation with yoke handling, but it's still with the goal of affecting yoke handling in order to prevent stalls.

</comment></comment></comment><comment><USER14> > Also, the airspeed, altitude and flight director pitch bar values from the > left side noted deviating from the corresponding right side values. The left > side values were lower than the right side values until near the end of the > recording

Hmm. Seems not just faulty AoA sensors? Perhaps some major malfunction in the flight computer? I've felt this entire time there's been a rush to claim 'faulty AoA sensors' because 'sensors' are known to fail, and it's an easy scapegoat.

My question is, does the flight recorder have raw inputs from the sensor, or just what the flight computer is reporting from the sensor? Seems like the latter.

<comment><USER32> Blaming the sensors seems pretty plausible, because the expected failure rate of that sensor is roughly 1:100000 and there have been about a quarter million 737-MAX flights since the plane was introduced.

<comment><USER14> But I just quoted 3 other sensors were reading off so...?

<comment><USER33> The problem is all those other things are CALCULATED values off the AoA sensor.

Literally everything depends on a single tube which is known to get clogged with ice, bugs etc.

So for the 737 Max, a single clogged AoA sensor causes all these things immediately and simultaneously:

\-- all your airspeed and altitude readouts go haywire, at least on one side of the cockpit

\-- a bunch of alarms start going off and a bunch of lights start flashing, each indicating a different problem

\-- your control stick starts shaking

\-- a little-documented system immediately commands the nose straight down into the ground, and keeps commanding it until turned off (but turning it off effectively prevents you from counteracting the nose down command)

Good luck.

</comment></comment></comment></comment><comment><USER34> > From 05:40:42 to 05:43:11 (about two and a half minutes), the stabilizer > position gradually moved in the AND direction from 2.3 units to 2.1 units. > During this time, aft force was applied to the control columns which > remained aft of neutral position. The left indicated airspeed increased from > approximately 305 kt to approximately 340 kt (VMO). The right indicated > airspeed was approximately 20-25 kt higher than the left.

This part is very interesting. This aircraft nose down (AND) trim occurred while the electric trim system was disabled. This means that either the pilots were moving the manual trim wheel in the wrong direction, or that aerodynamic forces were causing significant AND trim.

</comment><comment><USER35> To avoid FAA scrutiny, Boeing developed and deployed MCAS covertly. This was done because they feared scrutiny would have led to huge losses in the face of competition from Airbus. Had Boeing management just laid all their cards on the table, potentially the FAA could have still approved the design, with small but crucial improvements. These changes might have included: using both AOA sensors, using a 3rd AOA sensor, not switching between left and right sensors each flight. Instead, the covert nature of the development and deployment of this feature allowed flaws in its design to go unchecked.

</comment><comment><USER36> Imagine MCAS was never created. Instead pilots had to deal with the nose up stalls themselves. Would that have ended up being the outcome? Instinctively I feel like pilots could deal with the situation where MCAS was supposed to help, especially a lot better than when MCAS is dooming these two planes. What do you think?

</comment><comment><USER37> Imagine being the one who was forced to develop this. Regardless of whether one did see something like this coming and raised objections or missed it, I would be unable to continue to function. Do we know how teams cope with this?

</comment><comment><USER38> 1\. Using the input from a single AoA sensor as the single source of truth.

2\. Not ticking the box on the AoA DISAGREE alert option on the order sheet.

3\. Not using electronic override to neutral before STAB TRIM CUTOUT.

<comment><USER39> Boeing should be raked over the coals for even allowing item 1 to be a valid order configuration, and item 2 for being an order option.

</comment></comment><comment><USER40> Aircraft crashes attract a lot of attention, and probably for a good reason. But just to keep folks' internal perception of risk - aircraft safety has improved _a lot_ :

[https://www.edge.org/images/airtravelsafety.png](https://www.edge.org/images/airtravelsafety.png)

</comment><comment><USER41> This shouldn't be marked as a dupe since it's the actual report.

It sounds like they did everything right. There are two fateful moments:

>At 05:41:46, the Captain asked the First-Officer if the trim is functional. The First-Officer has replied that the trim was not working and asked if he could try it manually. The Captain told him to try. At 05:41:54, the First- Officer replied that it is not working

At this point they were in stable flight and the trim wasn't that extreme. An inability to manually adjust trim is a huge design flaw unless it was pilot error.

>At 05:43:11, about 32 seconds before the end of the recording, at approximately 13,4002 ft, two momentary manual electric trim inputs are recorded in the ANU direction. The stabilizer moved in the ANU direction from 2.1 units to 2.3 units. >At 05:43:20, approximately five seconds after the last manual electric trim input, an AND automatic trim command occurred and the stabilizer moved in the AND direction from 2.3 to 1.0 unit in approximately 5 seconds. The aircraft began pitching nose down. Additional simultaneous aft column force was applied, but the nose down pitch continues, eventually reaching 40° nose down. The stabilizer position varied between 1.1 and 0.8 units for the remainder of the recording.

They re-activated electric trim control but only slightly adjusted it. MCAS kicks in to send them nose down. There's no further pilot correction recorded. Again, unclear here if there is an airplane issue preventing them from adjusting trim or a pilot error.

<comment><USER42> The report was the basis for this article and discussion yesterday: [https://news.ycombinator.com/item?id=19570378](https://news.ycombinator.com/item?id=19570378). From Hacker News' perspective, since the report itself was prominently linked in the article and its contents were discussed directly in the thread many times, it qualifies as a duplicate.

<comment><USER43> How is that the same? The BBC article doesn't contain even 20% of the information as the full report (including multiple charts).

<comment><USER42> You're absolutely right, it's not the same (in this sense "duplicate" is a misnomer—or at least should be applied to the thread or topic and not the submitted link).

<comment><USER10> If that's the case, it would be appreciated if this was moved back, or at least re-posted. It appears worthy of being visible based on the amount of discussion it generated in a short time. Moving it to this thread effectively threw a bucket on the fire.

This document is a big deal.

<comment><USER42> OK! We've put it back.

<comment><USER10> Err...Not quite, its still under the poster of the bbc article, but the effort is appreciated nonetheless. You guys rock. :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER44> Reading through the chronology in section 1.1, it feels like a movie where the aircraft is a malevolent entity that's trying to kill them. So if I were in the cockpit I'm sure it would've been some mix of fear and anger. My life's not in danger though, so I'm only left with the anger, on their behalf, knowing some greedy bunch of assholes were effectively that malevolent entity, whose will was expressed via the aircraft.

EDIT: You guys can fucking blow me. Moderators ban my account please.

<comment><USER19> Why is that getting downvoted? What the heck.

<comment><USER45> > knowing some greedy bunch of assholes were effectively that malevolent > entity, whose will was expressed via the aircraft.

If this it true then link? When was this confirmed? Who are the assholes?

Else this is just Reddit spam that contributes less than nothing.

<comment><USER46> They would be the set of assholes who:

1) decided to move the engines forward making the aircraft dynamically unstable, but improve performance and potential sales

2) decided to counter the instability with a software system (MCAS) based on a single sensor, with zero redundancy or fail-safe mode, AND make a second sensor an optional extra cost for the airlines, AND bury the whole thing in a poor UI, in short: cheaping out on a band-aid fix to a critical problem of their own creation, to maximize profits

3) decided to evade normal requirements to make the airframe a new classification, so that airlines wouldn't need to spend money on retaining and separately qualifying pilots for the different airframe, again to reduce apparent costs of the new airplane and increase sales

4) minimized the training on the MCAS system and require no new training when they made changes to the system. AND make the MCAS system automatically re- engage, based on the single sensor to reduce customer costs

5) ensured that this cascade of bad decisions got implemented through the FAA and rolled out globally.

The effect of all of this was to overlook and minimize critical flaws in a complex human flight system, and do so in order to maximize sales and profits over safety.

They killed 346 people already, and nevermind the economic knock-on effects.

No, I'm not going to hunt back and provide a link to every bit of analysis I read gathering the above facts. It is all recent, non-obscure, and very google-able.

Yes, bad engineering and management decision that kill people will tend to get folks a bit riled up. This is a good thing. While this forum should indeed emphasize facts and intellectual argument, this is not a peer-reviewed journal, it is a forum for humans to discuss issues, and we should also keep here the human perspective on engineering.

<comment><USER8> > AND make a second sensor an optional extra cost for the airlines

This would be extremely egregious, but it's not what happened. Every MAX has two AoA vanes. Every MAX only hooks up the MCAS to one vane. The optional feature was just an "AOA disagree" light and display, which wasn't even hooked up to an error alarm. It's a red herring for these crashes, in my opinion. The pilots aren't going to hunt around the cockpit during an emergency and notice a disagree light and be able to conclude anything meaningful about what's happening to the plane and how to stop it.

<comment><USER47> They could have had "check for AoA disagree" as part of the pre-flight checklist though - I read somewhere that in at least 1 of the MAX crashes, the AoA vanes disagreed on the ground before departure.

<comment><USER48> Are they expected to agree when there's no airflow? What direction should they be pointing in?

<comment><USER8> You're right, they're literally vanes on the side of the aircraft, they don't do anything without airflow. Takeoff roll is when you could possibly first notice it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER49> Is there a demand for freight aircraft of this size? Conversation to freighters might be the best option for these planes.

</comment><comment><USER50> I really feel as we're entering an era where full automation is the only solution. This current paradigm of the plane telling the pilots "I don't know what to do here - handing it back to you" doesn't make much sense. Do we just need better multi-modal and redundant sensors so the plane isn't flying blind?

<comment> crooked-v This problem was one of too much automation, which decided that the best course of action was to fly the plane into the ground. In a less automated system, the pilots would have been able to enable electrical trim systems without also having their trim control overridden by MCAS and would have been able to recover flight control that way.</comment></comment>


Talking TypeScript with the engineer who leads the team - <AUTHOR> https://stackoverflow.blog/2020/06/15/talking-typescript-with-ryan-cavanaugh/ <comment><AUTHOR> The most interesting takeaway for me, was their opinion on Deno.

> _Q: Most of the time, TypeScript is transpiled into JavaScript. With deno, > It's a first class language. What do you think about efforts like that? And > do you think browsers will ever do TypeScript first?_

> _A: Deno is super cool. I love that someone's built this tech and is seeing > what would happen with it. I think the browser case is really interesting > because it seems like it makes sense. Then, every time I walk five steps > ahead in my head, it all breaks down for me._

> _So for me, it's like, OK, you're going to serve TypeScript to the client. > And then the clients can interpret the TypeScript. Well, if you're if you > don't want type checking on that file that you sent down, then there's > really no point. Stripping off the type annotations is a very mechanical > process and there's not a lot of value there. You can send down source maps > or whatever, but that's more of a diagnostic debugger experience. So we get > into this mode where we're sending this down as TypeScript so it can be type > checked by the client._

> _My first question is, why is this the client's job? Because you push this > TypeScript code up to the server, and I hope that it type checks at the > point that you did that. If it didn't, it'd be weird to consider why you > would have done that. And again, development scenarios are just totally a > different beast here. I'd like to see more investment in the development > space for questions like, would it make more sense to have that?_

> _But anyway, let's say we keep going and type checking on the client. Well, > you can't really start this type checking process until you've pulled all > your dependencies in. And then you're gonna end up sending down .d.ts files > that don't really do anything. And how did the .d.ts file get on your > server?_

> _I'm not going to say it's never going to happen, but I think there's a lot > more room for technologies like what you see with `create-react-app`, where > there's a live web server for development purposes, checking the types in > the background as it serves up the transpiled JavaScript on the fly. Like, > that's a fantastic model that renders all of my objections totally moot > because the type checking is happening at a more logical time. Maybe there's > some space for a browser plug in. But that model's a little confusing, too, > because ultimately your ` <scripts>` tag is going to pull in a .js file > unless suddenly all browsers everywhere support TypeScript. That's what > you'll have to do._

> _It becomes a question of if you're debugging or loading, say, production > HTML that references the .js files. Where in the process do we actually get > the .ts file instead? Never say never. But to me it's kind of a not soon > situation. Deno is completely its own thing because there it's a new > runtime. So that scenario makes a lot more sense to me, at least to be type > checking during the first time you run a script and making sure that you've > got some compatible environments._</comment>


Ask HN: Are you Enterprise, or Startup? - <AUTHOR> I've found myself reading a ton of HN lately, the quality is pretty high, and the topics only regularly make it over my head, instead of mostly, like the LWN.
I especially love OP ED pieces, no matter their quality, because it's kind of like a window into the soul of other developers, I'm not always looking to learn, sometimes I want to empathize.
One thing that isn't mentioned enough, is what environment you 'grew' up in as a developer. I think that shapes the way you write code more than almost any other factor, regardless of where you go after.
I think the Show HN: posts are the best examples of this. You have a huge volume of developers hoisting projects that solve problems in such a huge number of domains...I wish I knew why you wanted to solve a problem in that domain in the first place. I wish I had more background.
So I ask;
What world did you start in?
Did it shape the way you wrote code as you traversed your career? Where you predisposed to one environment over the other? <comment><AUTHOR> I'm still youthful in my career. I'm not yet 30, and I've been working professionally in Enterprise for 6 years. I barely empathize with the kinds of problems being solved with these 'Show HN' posts. It's not glorious development, but I don't hate working in these applications at all.

We have 3 main domains, that consist of modern technologies (Angular > C# WebApi > SqlServer) And 3 applications that are legacy, and still require feature updates (JSP / VB6 / ASP.NET MVC)

We move at a regular pace, and have access to great, expensive tools that I would probably miss in the start up environment. (Local TFS, Jira, Enterprise VStudio, iDea, local Sql instances)

I can learn so much, because the enterprise environment provides so much, and the jobs around here are entirely enterprise development(Philly).

I love the idealism in the West, but absolutely nothing about my environment makes me think the grass is greener over there.

</comment><comment><USER2> I work for a multi-national $BIGCORP by day, but in the course of my career I've worked for little 10 person companies, other $BIGCORPs, mid-sized consulting companies, other small-to-medium sized software companies, etc. I've kind of been all over the place experience wise.

Predisposition? I like the enterprise "world" in many ways, but I don't necessarily like working _for_ a $BIGCORP in many ways. In fact, I don't really like the fundamental _idea_ of having a traditional "job". My real passion is to run my own company. That's why I've been working on getting a software company of my own established. It's still a "nights and weekends" thing right now while the day job pays the rent and electric bill. But doing my own thing is my real passion.</comment>


The Ultimate Bubble? - <AUTHOR> http://www.vanityfair.com/politics/features/2009/02/wolff200902?printable=true&currentPage=all

<comment><USER2> US long-term treasuries are the ultimate bubble. When that one pops, history will be decided.

</comment><comment><USER3> This article is dated February 2009. It's still 2008. Print is so messed up...

<comment><USER4> Everybody wants to live in the future.

IIRC when a magazine has "February 2009" on the cover, it really means "take this off the newsstand by March 2009".

</comment></comment><comment><USER5> Why would the investors of P.E. continue to give up 2% in a deflationary environment when it could be year before the markets rise again?

<comment><USER6> The impression I got from the article is no new money is being pledged; PE firms are just calling in previous investments.

Those investors (like homeowners and the occasional VC limited partner) could default on their pledges, but that might prove even more costly -- in reputation, in loss of their other monies already stuck at the PE firm, etc.</comment></comment>


Microsoft selling 'Scroogled' merchandise to attack Google - <AUTHOR> http://www.microsoftstore.com/store/msusa/en_US/cat/Scroogled/categoryID.67575900%5C

<comment><USER2> That's kinda sad that they're reduced to taunting Google like this. I can almost smell the amused/condescending response from Google PR.</comment>


Ask HN: Avoiding techical debt - <AUTHOR>

I saw a another ask hn post today regarding technical debt and I wanted to ask this.
If technical debt is a big deal, KISS should be the most important decision. Let me elaborate.
Even before writing a single line of code, chosing the frameworks and or introducing a framework to you application stack is a big decision. For example, does your web app need a frontend rendering framework?
If there is a single engineer, he will be the devops, backend dev, and frontend dev. Even if the dev is familiar with angular or react, the simple introduction of such a framework is an immediate take on a debt. This is one way too look at it.
Do you just write the so called jquery spaghetti code that people frown upon so kuch these days? Or is writing jquery code more of a technical debt?
As a startup, do you slowly incur debt or immediately take on lump sum with more frameworks, betting that it will pay off. <comment><USER2> Recognizing, managing, curating, and killing technical debt is something that only comes with experience.

It's all about trade offs, and trade offs are informed by the environment they are in. When it's early and getting an MVP and revenue is important, you need to go with what you're comfortable with and have significant experience in. To do otherwise is going to distract you from the area you still need to explore and become an expert in: the business logic.

Really, this is why you'll see startup job postings saying they are looking for specific languages or frameworks: when they start seriously hiring for the first time, they need more people to help grow what they already have, no matter what that is, not people who want to come in and replace it with their favorite whatever.

There is no one-size-fits-all solution, and few technical debts are exactly similar. All are multifaceted and look different from different perspectives. What may be technical debt for one company, group of engineers, or at a specific time, may not be for another company, group, or time.

Presumably, before writing a single line of code, you aren't approaching the task totally green: your very idea must have been influenced by your abilities and experience. You should know if your web app needs a frontend rendering framework, and you're comfortable with one already or are willing to learn one in the short term. If you know JSON and are familiar with libraries and language support for it, don't bother looking at protobuf or thrift or serialization format du jour.

There will be technical debt, or at least there will be things that you know/think are technical debt that you wish you could have done differently. But that's the trade off you make. It's not going to be perfect ("perfect is the enemy of finished", or whatever that line is). The thing to do is make sure you're making informed decisions, know the tradeoffs, and that you're comfortable with them _at that time_. This is the only way to make progress, and progress is the most important thing, especially early on. Later on, progress will take on a different definition, which may include evaluating past decisions and recognizing them as technical debt and fixing them up (aka creating new technical debt).</comment>


Show HN: Draw, trade and battle cards (Angular, GAE) - <AUTHOR> https://www.runesketch.com/

<comment><USER2> This game is really cool!

</comment><comment><USER3> really cool!!</comment>


Multithreaded I/O - <AUTHOR> http://dobbscodetalk.com/index.php?option=com_myblog&show=Multithreaded-I-O.html&Itemid=29 <comment><USER2> Non-blocking I/O + coroutines handles this problem without the overhead of threads or the complexity of preemption.</comment>


Ask HN: How do talent acquisitions work? - <AUTHOR>

How are these types of deals initiated, negiotated, priced? Is it only realistic for US-based teams? <comment><USER2> A talent acquisition is often a polite way of saying that a small startup team was recruited to work at a larger company.

In many cases the company/product they are currently working on has minimal value, yet the team itself appears competent and strong, and likely possess some talent or skills that have value to the acquirer.

The purchase price of the deal is usually a fairly low number, and nets the founder and employees something closer to a signing bonus vs. a big sum of cash.

Like any acquisition, pricing and terms are all completely reliant on the specific situation, so it's hard to give much in the way of details.</comment>


Ask HN: How do you get users to use software? - <AUTHOR> I develop ERP software for companies internal use. Sometimes the software makes the user's life easier and they quickly start using it and are happy.
Other times the software introduces more process, more accountability, less autonomy. In these cases, the users complain endlessly that the software is too complicated. The clients in turn blame us when the users refuse to use it or find work arounds.
I feel like this is a management problem and not a software problem. But I don't know what to tell these managers to incentivize their workers to use the software.
I need practical recommendations, but it would also be nice to have an authoritative source for recommendations. <comment><USER2> It will vary from manager to manager depending on their level and the individual personality, but just remember the golden rule that generally speaking all middle management is looking to either advance their position in the company or at least better their standing within it. With that in mind it makes life much easier because now you just have to communicate your product to that end.

Find out the goals of the managers' bosses, and prepare a small brief of empirical evidence that explains that you understand what their bosses want and how your product can help meet those needs. If you are skillful enough, you should try to communicate this in a way so that you only provide just enough info and indirect hinting that they arrive at the conclusion on their own rather than you giving them a conclusion. Remember the second golden rule that humans are fundamentally emotional. If you provide all the answers for them and they dont know you or trust you, they're more likely to just dismiss it all regardless.

</comment><comment><USER3> I have found that users, especially in a business setting, will happily adopt new software as long as the benefits of using that software exceed the pain of adopting it.

> In these cases, the users complain endlessly that the software is too > complicated. The clients in turn blame us when the users refuse to use it or > find work arounds.

This reaction sounds a lot like the software is incurring more cost on the users than benefit.

Are you sure that the software is not, in fact too complicated? Are you sure that the companies using your software aren't misusing it in a way that increases complexity and cost to the actual users?

> I feel like this is a management problem and not a software problem.

Why do you think this? You haven't gone into enough detail for me to really know, but it sounds to me like the software is either too complicated or foreign to the users, or that the software is being used in an inappropriate way.

<comment><AUTHOR> The benefits to the low level end users don't exceed the pain. The benefits accrue to the upper level managers. For the low level end users it is

> more process, more accountability, less autonomy

It is complicated. It is foreign to the users.

The question is how do you incentivize workers to adopt software that makes their live more difficult, but helps hold them more accountable and with less autonomy. They often make decisions that make their life easier but lose money for the company.

</comment></comment><comment><USER4> > users complain endlessly that the software is too complicated.

Try to solve that problem? I realize I'm over simplifying it but have you really done everything you can to simply and streamline the software for the user?

<comment><AUTHOR> yes i am 100% positive.</comment></comment>


More States Opting to 'Robo-Grade' Student Essays by Computer - happy-go-lucky https://www.npr.org/2018/06/30/624373367/more-states-opting-to-robo-grade-student-essays-by-computer <comment><AUTHOR> > Developers of so-called "robo-graders" say they understand why many students > and teachers would be skeptical of the idea. But they insist, with computers > already doing jobs as complicated and as fraught as driving cars, detecting > cancer, and carrying on conversations, they can certainly handle grading > students' essays.

> One year, she says, a student who wrote a whole page of the letter "b" ended > up with a good score. Other students have figured out that they could do > well writing one really good paragraph and just copying that four times to > make a five-paragraph essay that scores well. Others have pulled one over on > the computer by padding their essays with long quotes from the text they're > supposed to analyze, or from the question they're supposed to answer.

The science is just not nearly there yet. We can barely determine the sentiment of IMDB reviews. How should we be able to grade an entire essay?

Working in NLP, it really bugs me when people overstate what can be done like this. It creates massive expectations that are bound to fail, and then the entire field suffers.

<comment><USER2> > Working in NLP, it really bugs me when people overstate what can be done > like this.

But they have to. Otherwise funding goes away.

> It creates massive expectations that are bound to fail, and then the entire > field suffers.

Yes. But by then the people overstating now will have made their money and moved on.

I agree with you, but honestly companies and investors are so shallow it isn't hard to see what is going on.

<comment><USER3>
       > Yes. But by then the people overstating now will have made their money and moved on.

Yep, and those people will likely be sending THEIR kids to elite private schools with 5:1 student-teacher ratios and 20-40K/year tuition for elementary and high school. These schools will DEFINITELY NOT use "AI" for grading.

<comment><USER4> It's weird that what is luxury today was once the norm: organic produce, a stay at home parent, natural (as opposed to synthetic) clothing, etc.

I won't be surprised if having human teachers / caregivers will be reserved for the upper classes.

</comment></comment></comment></comment><comment><USER5> If you apply to study at the University of Cambridge (UK, not Boston), an actual faculty member (not a teaching assistant or anything like that) of the University of Cambridge (not some lesser institution) will take the time to sit down with you for an extended period of time for an interview, even for undergraduates (for graduates, it goes without saying). That courtesy is extended to a boatload of applicants who make that final stage, and the stages before that certainly don't involve robo-grading.

In the U.S., you take the SAT or GRE or whatever which gets graded by a mechanical turk or even an actual machine. And even the good colleges don't have the good sense to ignore the thing (the exception being MIT, at least back when I applied there, where stating your GRE score was optional when you applied as a grad). So a less than astronomical score will immediately make it impossible to get into any decent college. That system is f*cked up.

For me that meant that the only university that would have me also happened to be the university that routinely scores first or second place in international university rankings, that university being Cambridge. And I didn't get a single offer from the US because of a bad GRE score.

After getting my doctorate in NLP there, I can attest to how fucked up the idea actually is, that you can score essays using NLP.

<comment><USER6> The sicker idea is this whole business of "We'll use machines to do human work, and badly, cause it saves a significant amount of money", is endemic to the US at large. And sure, it makes a lot of money right now, which is what the stock markets and VC's care about.

I can highlight individual companies (Google, Facebook, Amazon... etc.) and they all use various forms of "AI" (cough) to do all sorts of human related tasks. And they do it somewhat ok for the standard case, but fail horrendously all around the edges. But the failing around the edges is an intended side effect. It costs too much to do it right, so "right now" is what's selected for.

It's also why HN, Twitter, and Facebook is the final customer support solution. That's because their customer support portals are echo chambers of "we're very sorry, but we really dont care".

</comment></comment><comment><USER7> This seems easy to game, especially if you have any insight into the model behind the grading. I doubt that those running it will release any specifics, but with a large industry[0] behind test prep, general guidance on how to beat the system will be available for those who can pay for it.

That said, the SAT writing section was equally silly when graded by humans. All of the examples of what a good score looked like (per when I took it ~10 years ago) were highly formulaic, rewarding those who invested in played the game.

[0]: [https://www.quora.com/How-big-is-the-SAT-test-prep- market](https://www.quora.com/How-big-is-the-SAT-test-prep-market)

<comment><USER8> If you read the article it actually goes into a lot of fun details on how it is _already_ being gamed. GAN techniques where you just generate garbage to get a high score:

> Called the Babel ("Basic Automatic B.S. Essay Language") Generator, it works > like a computerized Mad Libs, creating essays that make zero sense, but earn > top scores from robo-graders.

      "History by mimic has not, and presumably never will be precipitously but blithely ensconced. Society will always encompass imaginativeness; many of scrutinizations but a few for an amanuensis. The perjured imaginativeness lies in the area of theory of knowledge but also the field of literature. Instead of enthralling the analysis, grounds constitutes both a disparaging quip and a diligent explanation."

Along with human examples:

> One year, she says, a student who wrote a whole page of the letter "b" ended > up with a good score. Other students have figured out that they could do > well writing one really good paragraph and just copying that four times to > make a five-paragraph essay that scores well. Others have pulled one over on > the computer by padding their essays with long quotes from the text they're > supposed to analyze, or from the question they're supposed to answer.

This whole thing is a nice case study for adversarial machine learning.

<comment><USER9> Just because the essays are auto graded doesn't mean no human will ever see them. It takes far far longer to grade an essay than it does to skim 3 sentences randomly and confirm that it's bullshit and get the student expelled for attempting to cheat.

<comment><USER10> That will stop people from just copy-pasting one statement over and over again. But, it will still create a meta game of trying to write machine learning likable texts as opposed to good texts.

<comment><USER11> It was already a bit of a game in 2005 when I took the 'new' SAT which included an essay component. Research from the same professor Perelman quoted in this article had shown that longer essays were graded more favorably (by overworked humans I believe), so I made sure to fill the whole space at the expense of quality writing, and got a perfect score.

[https://mobile.nytimes.com/2005/05/04/education/sat-essay- te...](https://mobile.nytimes.com/2005/05/04/education/sat-essay-test-rewards- length-and-ignores-errors.html)

</comment></comment></comment></comment></comment><comment><USER12> I'm surprised they didn't even mention the morale issues. How will it feel to know your answer isn't even going to be read by a person?

<comment><USER9> Math homework can be auto graded as well. I wouldn't shred a tear that no one reads whether I got the arithmetic questions right or wrong. The point of all the works is to improve your abilities. Your first short story written at the age of 7 isn't going to be a blockbuster, it's just trash you write to improve your ability to write. Using robo grading means more absolutely horrible essays that have no value on their own can be written and graded without a teacher having to spend the huge amounts of time it takes to grade them.

<comment><USER13> I think that robo-grading is missing the ability to give cohesive feedback on someone's performance. A teacher who reads a students papers over the course of a year (or years) will be able to provide guidance to the student on how to improve. The robo-graders might be able to spit out a semi-accurate grade, but they won't be able to tell the student what they could improve and how.

<comment><USER14> What's more, with black box ML techniques it may be the case that "advice" exists, but that it cannot be effectively interpreted.

</comment></comment></comment></comment><comment><USER15> If the teachers are using automatic grading, the students should be allowed to use automatic answering.

In fact, why not stay at home and all interaction can take place via Google's Duplex!

</comment><comment><USER16> Stating that multiple choice tests are free from bias is already highly suspect.

The decision-makers on this seems to be both tech illiterate (or with hidden agendas) and hilariously arrogant to the point that they seem to think that epistemology is something that happens to other people.

</comment><comment><USER17> "they insist, with computers already doing jobs as complicated and as fraught as driving cars, detecting cancer, and carrying on conversations, they can certainly handle grading students' essays."

Except that computers can do none of those things, and those three things are all much simpler tasks than critically grading a student's essay.

Also, of course the companies selling these products will say they work great. That's the very very last person to trust in the conversation.

</comment><comment><USER18> Honestly it might be better than the current system.

I graded papers for national high school exams for a few years (non-US) and there was a strict grading guide that you had to follow which took out any and all subjective grading out of the question.

The essay section grading guide was essentially a template that was a must to follow and any deviation would result in panalties.

You had about 30-45min to grade exams that could take 4-6 hours for students to complete and none of the questions were multiple choice they were all long form questions. With ~30 questions per exam, the time included saving the answers in the electronic grading pad and in the later years in the shitty VB application they provided. (Which I ended up hacking and having a spread sheet import function, this got me kicked out of the exam grading because I tampered with the application...).

We are already robograding papers just with mechanical Turks and in a process which is much less accurate which is why we use 2-3 graders per exam.

Until we find a better overal solution for evaluating student performance I don't see anything wrong with robogradig exams and student work if anything it might give teachers some more free time to actually teach.

</comment><comment><USER19> I think the reality of this is fairly well captured in the 4th to last paragraph

> Even human readers, who may have two minutes to read each essay, would not > take the time to fact check those kind of details, he says. "But if the goal > of the assessment is to test whether you are a good English writer, then the > facts are secondary."

I would go a step further and say the goal of standardized tests is probably not to test if your a good English writer but rather to see if your good at that test. AI has tremendous ability to streamline the grading of standardized tests which are narrowly focused measure and I think that's fine if it comes with proper checks. As many people mention here I don't think AI will be able to objectively measure good general writing and I doubt we'd fully cede artistic evaluation to a computer as a society but I agree with being weary of this.

Standardized tests in general though seem to me like one of the greatest examples of a measure becoming a target and loosing a lot of its effectiveness (Goodhart's law). I can't help but be reminded of Paul Grahm's essay on nerds[1] by this article because the effective point of school from an evaluation standpoint is these tests. However now we've built a computer that grades these test's nearly as well as its human counter parts and its glaringly obvious that this evaluation is tremendously game-able. Which resonates with Paul's argument that: "The problem with most schools is, they have no purpose."

[1] [http://paulgraham.com/nerds.html](http://paulgraham.com/nerds.html)

</comment><comment><USER20> >> _But Nitin Madnani, senior research scientist at Educational Testing Service (ETS), the company that makes the GRE 's automated scoring program, says [...] "If someone is smart enough to pay attention to all the things that an automated system pays attention to, and to incorporate them in their writing, that's no longer gaming, that's good writing," he says. "So you kind of do want to give them a good grade."_

The presence of this quote in the article makes my day; doubly so given its source. It's a picturesque example of a statement that could conceivably get a 10/10 from a robo-grader based on the language and structure, but the thinking it represents is completely backwards.

<comment><USER21> Write to your audience! That's always the best rule, and a reasonable metric for 'good writing'. If the audience is a robot...

</comment></comment><comment><USER22> I heard a recent radio ad pushing a "Work from home as a Medical Coder" training seminar. Sounds dubious.

I wonder if you could create a legitimate service that provides "Work from home as an Essay Grader."

<comment><USER23> I stumbled upon this company at ISTE.

They outsource essay grading, similar to what you are suggesting.

[https://www.thegraidenetwork.com/](https://www.thegraidenetwork.com/)

</comment></comment><comment><USER24> edX can automate short essay grading with edx/edx-ora2 "Open Response Assessment Suite" [1] and edx/ease "Enhanced AI scoring engine" [2].

1: [https://github.com/edx/edx-ora2](https://github.com/edx/edx-ora2) 2: [https://github.com/edx/ease](https://github.com/edx/ease)

... I believe there's also a tool for peer feedback.

<comment><USER25> Peer feedback/grading on MOOCs is pretty bad in my experience. There's too much diversity of skills, language ability, etc. And too many people who bring their own biases and mostly ignore any grading instructions.

Peer discussion and feedback are useful in things like college classes. Much less so with MOOCs.

</comment></comment><comment><USER26> > Marder and Henderson worry robo-graders will just encourage the worst kind > of formulaic writing.

> they will quickly learn they can fool the algorithm by using lots of big > words, complex sentences, and some key phrases - that make some English > teachers cringe.

Spot on! That's already the case with real teachers, with a computer it'll be hundreds of times easier (and horribly counter productive for the students' formation).

Back in the day, when I was a student, we already did a LOT of padding in our essays: writing pages upon pages (length mattered enormously!) of loooong sentences designed to -basically- make the discours look much more clever (and accurate) than it really was. I'm still puzzled why our teachers did not notice the obvious B.S. that it was! Seriously, I managed to pass some classes (university) with almost no real meat in the text. I just managed to write a coherent & logical argument, with a minimum of (vaguely remembered) facts, and that was enough to get a passing grade (but not a great grade of course). Ridiculous.

\---

Another fundamental problem is that even teachers don't have the same views upon what is a good essay. For the worst essays, I think they will agree: bad grammar, typos, no paragraphs, no logical structure, etc. But once you enter the average (or more) quality it becomes much more difficult to agree on which text is better! There is a LOT of subjectivity and personal taste, no matter what directives were given from the educational board, so your results would vary a lot depending on your current teacher.

Some teachers for instance are very narrow-minded, they expect students to "regurgitate" their lessons almost word by word, others appreciate a student's attempt to insight & originality / independence of thought. I've been in the french education system for a long time (including 6 years in 3 different universities), and it was shocking to see how much of a grade would depend on the teacher & of their perception of you (because that's also a factor, even if the teachers will swear it's not the case).

Even for technical subjects it's not obvious AT ALL that the teacher is right and rewarding the best answers. Now that I have many years of programming/projects management behind me, I see plainly the mistakes & B.S. that some teachers would give us. And I've had coworkers who were still part- time students explain some of the incredible misconceptions of their teachers, it was almost beyond belief! Those teachers really lived in another world, they had no clue.

Well, at least, if you are graded by a program, you know that you will only have to learn that program's "tastes/patterns", instead of facing the unknown of being graded by a random teacher (who may like your style or not). That's a small consolation.</comment>


Timeline: ESA spacecraft and station track critical arrival at Mars - <AUTHOR> http://www.esa.int/SPECIALS/Operations/SEMWS4TX55H_0.html

<comment><USER2> For those who haven't seen it, JPL has a nice animated simulation of the landing. It operates in realtime, with a button to advance to just before the time of the landing:

<http://eyes.jpl.nasa.gov>

It requires Java, and you'll need to grant it permission to run.

<comment><USER3> That was fantastic, thanks for sharing. I wonder if they use Celestia or something to create that. I would really like to know how they created that.

<comment><USER4> It certainly looks similar—one thing you might have noticed is that the entire rest of the solar system (including some mid-sized asteroids) is in there and decently textured. Really terrific!</comment></comment></comment>


Compression with the Burrows-Wheeler Transform - <AUTHOR> http://james.fabpedigree.com/bwt.htm

<comment><USER2> Unless I missed it, this page doesn't actually contain a description of how to invert the BWT. Fortunately, Wikipedia has a fairly decent description:

 _The inverse can be understood this way. Take the final table in the BWT algorithm, and erase all but the last column. Given only this information, you can easily reconstruct the first column. The last column tells you all the characters in the text, so just sort these characters to get the first column. Then, the first and last columns together give you all pairs of successive characters in the document, where pairs are taken cyclically so that the last and first character form a pair. Sorting the list of pairs gives the first and second columns. Continuing in this manner, you can reconstruct the entire list. Then, the row with the "end of file" character at the end is the original text._

</comment><comment><USER3> This algorithm is highly useful for next-gen sequencing.

Heng Li, the creator of MAQ, has recently released an aligner called BWA. The heart of BWA is the Burrows-Wheeler transform. The benefits? For genome research, they include a small memory footprint (<4GB), and fast exact matching of short reads to a reference.

Text compression, meet genomics. Genomics, meet compression.

</comment><comment><USER4> In my mind, Burrows-Wheeler is a clever trick, but it's not clearly superior to dictionary-based methods. bzip2 beats gzip on compression not because B-W is better, but because it has a larger window size and because of the entropy encoder at the tail end.

7Zip builds on gzip, greatly expanding the window and using an arithmetic encoder at the tail end. It performs better in both time and space over bzip2, making both gzip and bzip2 obsolete

<comment><USER5> In tests I've seen, LZMA -1 is even slower than gzip -9 so I wouldn't say gzip is obsolete in situations where compression speed matters.

</comment></comment><comment><USER6> It's funny that the article mentions gzip but not bzip2, which is also commonly installed on Unix systems and uses the Burrows–Wheeler block sorting transformation (followed by Huffman coding).

</comment><comment><USER7> The original Burrows & Wheeler paper, SRC Research Report 124: [http://apotheca.hpl.hp.com/ftp/pub/DEC/SRC/research- reports/...](http://apotheca.hpl.hp.com/ftp/pub/DEC/SRC/research- reports/abstracts/src-rr-124.html)</comment>