People forget a project was late if it succeeds, they never forget a project on time that failed because it was rushed, buggy and not polished production.

MBA/business and marketing need to go back to letting the product people and engineers create value, then they can extract the value and sell it. It is much easier to sell value of a good product, it basically sells itself. For some reason American business has completely forgotten the rule this millennia, product then marketing and selling.

You see this same thing happen at game companies when they put a date out there and it is driven by management and marketing over reality of engineering/product/design that makes a fun and solid game.

Boeing was greatly diminished in engineering/product excellence by the McDonnell Douglas management control takeover, everything newly produced since has the tell of this.

The problem is the 737 Max was hustled quickly to market to beat airbus and especially to offer a "drop in replacement" to existing earlier generation 737. Boeing would have definitely lost market share if they hadn't gotten their plane out then.

Choosing technical debt involves economic logic for today's marketplace. I suspect the real problem is companies wind-up deluded by their choice - to hustle the 737 Max to market, Boeing had to pretend is wasn't a, uh, piece of crap. Or not a piece of crap but a terrible mix of high tech and low compromises. And this pretending had to go through the whole enterprise. The marching order couldn't be "we'll add few more stiches on this Frankstein and hope the guts don't spill out", they had to be "this will be one more product of Boeing excellence" and everyone either believes or acts like they do. and this situation, combined with the huge investment involved, makes cutting losses very hard.

#notallMBAs, but the surest way for your product to fail on the market is for your company to go bankrupt before you’ve polished it enough.

In this specific case it was about greed, but sometimes MBAs push for release, because according to the engineering teams the product is never truly perfect

Product people and engineers know how to manage time probably better than business because they are doing the work.

If something fails because it doesn't meet the market there are numerous reasons for that besides not hitting the date.

A good product, that hits the date, can still fail due to market timing or market movement and many other things. Whether a project is launched at a certain date has little bearing on the success of that project long term, short term it might meet marketing and financial quarterly goals, but long term success is always better when it is a good product, and for it to be a good product the people that make products and create value should determine or at least have some say when it is complete and ready.

It's not my favorite solution for every application, but it's a good tool for a handful of situations. And it's a good way to avoid having to think about picking who to trust with only two sockets. There are other approaches, of course. For example, if your system can afford more than a couple clock cycles of latency (e.g., if you don't believe you can crash a plane with a couple milliseconds of control error) you can do the same thing with well-designed software and a bit of extra hardware. It gives you more freedom since there's more hardware to buy, at the expense of engineering and test effort to prove that your solution does what you want.

Doing this over large physical distances also adds some challenges. There are debates around dedicated signal wires direct between control centers vs data networks. Every situation is a little different, so there aren't really easy answers that you can swoop in and prescribe as best-practices. In general I find that people are more-skeptical of packet-switched solutions (e.g., Ethernet) than I would be. But most folks are also better at reasoning about the failure modes there than they are at thinking about the lower-level issues that Ethernet solves for you. And of course there are tons of different signaling systems - not just Ethernet - to consider.

Consider just a few different possible applications and the constraints that they impose. A car has less severe failure modes (many crashes are nonfatal) but less freedom in time. Your trajectory is simply more cluttered. A passenger plane has dramatically more energy, so failures are typically more severe, but you have a lot more time to deal with them because your trajectory is empty (much of the time, anyway). And if you're sane, you've designed it to be passively aerodynamically stable because twitchy maneuverability isn't critical when you're not a fighter jet. A rocket is a different animal altogether. Those are often rigged with self-destruct explosives, and you don't really get much time to change your mind if you erroneously choose to trigger them. Plus they're typically less stable (performance is more dear, gravity isn't helping you, and purely aerodynamic solutions don't take you outside the atmosphere) and are thus more dependent on their control systems.

If the majority of computer aids turn off, the plane doesn't simply drop out of the sky. It reverts back to a more complicated, but human-controllable, vehicle.

From the article (and who knows how much Bloomberg understood) the active-active sounds more like recognizing, not recovering from, errors.

Which isn't the worst idea. Pilots being, well, pilots.

So you're asking the pilot to, in the midst of some other failure, to start flying a weird plane they ever flown before. You could solve that problem by training all your pilots in this BUT this solution is very expensive, so expensive the airlines might just demand their money back instead. And that wouldn't be a solution for Boeing.

And now, the FAA (or EASA) might just mandate that anyway.

I wouldn't be surprised if CAAC refuses to ever recertify the 737 MAX, especially if a trade deal isn't struck.

The benchmarks and excitement around AMDs offerings are a great example. When you see something that presents a paradigm shift, often the market will not have fully digested it.

AMD is one of those cases, and I believe BA is as well. Their stock is essentially unchanged from where it was before the Lion Air crash in October 2018. This company is worth $200B and we’re talking about 5,000 units of a $100mm plane (that’s $500B in revenue right? I’m not adding a zero there?)

My layman understanding is that actual prices would be around 40% off list price for models that sell really well, with little competition (for instance A321). Much steeper discount above 60% for models that have a hard time selling (A330NEO) or for end of line to close a production gap (777-300ER is very cheap to buy while Boeing is working on the 777-9).

Computer Scientists aren't usually taught engineering ethics and definitely get fired all the time for arbitrary reasons.

OTOH, I'm skeptical those courses change behavior, and in this particular case others in comments are saying this is a common architecture in the space, so how could anyone solve this ethical conundrum if getting to the base level of whether this is an ethical conundrum to begin with is difficult?

In that environment, serious ethical concerns could easily be brushed aside as "coders just being coders". When Google got found out for making drones, the employees of a company staged a 5 minute walkout.... that was it, I'm sure some people quit, but not enough to make any impact

>marketing themselves as "COOL TO WORK FOR"/"WE HAVE BEER ON FRIDAYS",

"the idea that you are small and need management to tell you exactly what to do everyday, because you're a dumb idiot who spends all day watching anime and playing video games" does not follow.

Note that the UofI has always been in the top ten nationally for CS; its 2020 rank is #6 (behind MIT, CMU, UCBerkeley, Georgia Inst. of Tech, and Stanford).

1: 2005: https://web.archive.org/web/20050321215749/http://courses.ui...

2: 2019: https://cs.illinois.edu/academics/undergraduate/degree-progr...

I liked my ethics course in the philosophy department, but that's more about J.S. Mill, and Kant and the rest. Engineering ethics was a course any Eng. degree had to take, interesting, but hard to apply also. You go through case studies and look at them, but to have any productive class discussion they kinda have to be broken down to be at least somewhat clear and concise.

I don't feel like getting into here, but I feel like even this Boeing issue, which is pretty clear, is less clear than any case study in a textbook.

Its also my understanding that most do.

BTW: SE typically means Software Engineering in this context.

And, 100 scenarios instead of 10? I sure as heck there's more than that on an architecture redesign!

The National Enquirer may be more reliable than Bloomberg at this point.

>Collins reorganized business units and retrained managers, with an eye toward efficiency and speed. It pushed its suppliers to do the same, and established partnerships with companies such as HCL Technologies, which provides outsourced, lower-cost engineering services from India.

>Along the way, Collins unseated Honeywell as the provider of flight control computers on a predecessor of the Max, the 737 NG, and supplied numerous systems for the Boeing 787, which went into operation in 2011.

>When Collins secured the contract for the Max displays in 2012, it credited the belt-tightening. “There were a lot of cost-saving measures — a lot of tough decisions — that had to be made,” one manager said at the time in a company publication.

https://www.nytimes.com/2019/11/07/business/boeing-737-max-c...

If there was a problem with the master-slave operation on the MAX, not necessarily connected with MCAS, might not the same problem exist on the 737 NGs?

the MAX added new engines, which required forward placement on the wings, which changed COG, which necessitated MCAS.

http://www.airbusdriver.net/airbus_fltlaws.htm

That's not really a thing in modern airliners. The computer is still heavily involved even when hand-flying the plane.

As for "modern", the A320 had control laws in 1984 and the 777 in 1994.

https://www.aviationtoday.com/2019/05/06/boeing-angle-of-att...

Former engineering powerhouses like HP, Boeing, and IBM slowly get hollowed-out into incompetence when it’s assumed that Engineering and technical skills don’t require a considerable depth of knowledge and experience.

could it also be the normal generational rotation of people through the organization?

Everyone grew at a tremendous rate since the 1960's. Many, many more engineers. And then they retired.

The most effective leadership for a technical company is leadership with actual technical creds to back it up.

The technical side is a must because you need someone who actually understands the business and the innovations that must takes place. But you also need someone who can provide the people-leadership skills and the business wheeling&dealing.

These are all crucial skills and take up a persons time, so it’s not uncommon to see this come in the form of a duo (Apple and Steves, or Microsoft with Bill+Steve).

The software was fine (or at least not to blame). Unstable aeronautic design and lack of redundant sensors was the real problem.