Legit Teams: Private git repository hosting tailored for small teams - <AUTHOR> https://legitteams.com/

<comment><USER2> You seem to be heavily focussed on Github's financial costs, but why should I use this over something like Bitbucket, which provides free hosting for small teams and very reasonable pricing for teams?

<comment><USER3> As the owner of a small non-profit with real turnover, I would much rather use something like this.. just my two cents. We've had issues with holdover accounts costing us even after our developers are no longer actively involved. It makes a lot more sense to charge based on storage space.

<comment><USER4> Both systems makes sense, because it depends on your situation. There is no better, its just different.

</comment></comment></comment><comment><USER5> It's undeniably an awesome deal and I really like the website design.

I get a little concerned about the business model. Almost to the point that it would prevent me from hosting my code with them for fear of them going out of business or raising their prices later.

The current git repo for the commercial product I work on is 850MB. This is millions of lines of code + 8-9 years of development (migrated from svn at some point). That means we could be happy at the $5 month range.

If you get 1000 customers X $5, you're making $5000/month. I make way more than that as an employee.

Of course, you have people that will need more than 2GB but I think it's rare.

tl;dr raise your prices. I think it will help you get more business.

<comment><AUTHOR> We created Legit Teams because we ourselves needed a service like it. As such, we don't view this as a business that's going to make us millions of dollars so much as a product that we'd love for both us and others to use. In turn, making enough money to simply handle our costs is really enough for us to keep this going.

tl;dr We're not raising prices or shutting Legit Teams down because it's not a business, but a tool that we use, and will keep using. Having others on board is a bonus! :)

<comment><USER6> What happens when you become large enough to justify an organization account at GitHub and it no longer becomes beneficial for you to either use or continue to operate Legit Teams?

<comment><USER7> Push to GitHub since every Git repo retains full history by default.

<comment><USER8> I think the question was directed at the founders, not the users. What happens to the users of the service when the founders no longer have any use for it?

</comment></comment></comment></comment></comment><comment><USER9> Bitbucket offers unlimited private git repos for individuals and small teams (upto 5 people) with no limits on storage... for free.

<https://bitbucket.org/plans/>

</comment><comment><USER10> Competing on price - this is very low margin, even with negligible storage and bandwidth costs - when GitHub is already in the "dollar per repo" range seems like a good idea until you realize that your target market (poor students) might not want to give you anything.

I strongly recommend that you read the first of the Copy Hacks books: the one on messaging. Key is the insights on identifying the motivations of your users.

Best of luck!

<comment><USER11> Do you have a link for "the Copy Hacks books"? Haven't read about them.

<comment><USER10> <http://copyhackers.com/>

Sorry for the delay!

</comment></comment></comment><comment><USER12> We're a small business with 20+ repositories and faced this problem long ago. GitHub pricing simply isn't tailored for small projects. We moved to SpringLoops which only charges for "active" projects, so we can close those projects that only get opened for an occasional fix/compile. I really miss GitHub and all the new features, but can't complain for the price.

</comment><comment><USER13> Just created a test account. Pretty slick for a side project. Love the TODO list feature. Like others have mentioned i too worry about the pricing though. I have several people pushing each day and pulls from multiple servers as i deploy straight from the git repo. Slow pushes are the worst and at this price range i dont see you guys making that work once people really start using your product.

I think it actually looks better than bitbucket which some have mentioned which to me looks really cluttered.

I am not a student though so maybe i should not be looking at this as an option for a business anyway, but still...

<comment><AUTHOR> Thanks for the kind words.

I can't foresee all scaling issues that may come to pass; for what it's worth, I can tell you that I have trust in the people behind Legit Teams to solve these problems.

In turn, I can only ask for you to try our service and see if pushing becomes a problem. I'd then love to hear your feedback via our contact page based on your experience.

</comment></comment><comment><USER14> Very nice. It looks like something I could use except that most of the repos I work on are public.

But I think evanbarter's question is valid: why this over BitBucket? Any compelling reasons...

</comment><comment><USER15> 2GB of space isn't all that much. That's the free plan assembla offers. We blew through it with a year of general disciplined use but every once in a while we dropped a DLL or game asset in and so the 3 people generated 2GB of git in a year. While it's possible to get rid of such assets from history permanently its complex and risks other data loss if you're not extremely cautious.

Just feedback to say that arranging for custom plans at 2GB seems low.

</comment><comment><USER16> Immediately, the opening paragraph states that this service would be useful to "college students." However, Bitbucket offers their full unlimited package to college students with a .edu account, and this account lasts for a lifetime, even after graduation. Perhaps you could offer this deal to college students as well.

</comment><comment><USER17> This is great. As a freelancer, I often reluctant to delete past client's repo. With this, I can keep all past projects' repo without blowing my wallet.

Edit: It would be great if they add support for DSA too.

</comment><comment><USER18> So far, I loved the very polished interface and the reasonable pricing (this coming from a RepositoryHosting costumer). I'll push some code to try out. Congrats and good luck!

</comment><comment><USER19> Just curious - how are you planning to address the problem of ssh key lookup at scale ? Github hacked its own PAM module to read from MySQL, if I'm not wrong.

<comment><AUTHOR> As far as I can tell, GitHub uses one git user to grant repository access to everyone. This introduces SSH key lookup problems because all GitHub members need to be authorized under this one user.

Legit Teams, by contrast, allocates an individual user per member who signs up. Thus, SSH key lookups are limited to only the keys that one person has. Correct me if I'm wrong, but I believe this circumvents the scaling issue entirely.

</comment></comment><comment><USER20> Codeplane is also a nice alternative. They offer 2gb for just U$9/month.

<https://codeplane.com/>

</comment><comment><USER21> Competing on price is just fine. Please don't complicate things. I don't want anything else. Just a private repo will do. Thank you.

</comment><comment><USER3> Sweet deal, guys. Keep up the great work

</comment><comment><USER22> Excited to see this up and running!

</comment><comment><USER23> Looks pretty promising</comment>


Ask HN: What tools do you use for fundraising? - <AUTHOR> I am curious to  learn what tools do other founders use for managing the fundraising process - finding connections (via LinkedIn & AngelList), tracking pitches, finding other investors in the space.
I haven't found anything online which seemed to fit the bill and it seems like a problem that has probably been solved.
So how did/do you manage the fundraising process? <comment><USER2> I've raised a $2M Seed and $6M Series A, used Google Sheets for prospect tracking both times. The process was pretty simple: we'd add investors to the list, stack rank them in order of preference, contact them, and then use color coding and a status column to keep track of where they are in the process (BLUE="need intro", YELLOW=contacted, RED=declined, GREEN="term sheet", etc.)

<comment><USER3> Hey I have a question for you. I would like help writing an extensive business plan, since VC's have asked for one.

I've found a qualified consultant who already did work for me and would be willing to do this on a deferred basis. Can I include this expense in your opinion? It's under 6k usd but would have to be paid out of the budget. The person said that someone they asked said VC's don't like to pay for any past expenses.

thanks for an opinion.

</comment></comment><comment><USER4> We didn't. Though, I'd suspect most would use any kind of a project tool already used for everything else they're doing (for us this was Trello).

As to where to find investors, we just dug into our current relationships and cold called people in similar verticals until we found people that wanted to hear us out.

Maybe it's different culture in the bigger tech hubs, but early investment is really personal for us (not something you find on angellist or LinkedIn). It was important that it came from someone we at least partially knew already or was familiar with what we are doing through the grape vine.

After that it was just relentless persistence until we landed a decent angel. Lots and lots of drive time and hand shaking, but no smart app or toolset.

</comment><comment><USER5> Just keep a list of interested potential investors.

As a founder you should be explaining the business to everyone and listening to their reactions. That means everyone - including other-sector people, non- tech people, your family, your friends, your neighbors, random shopkeepers, people in the lift, people in the carpark, people on the plane. If they are bored or zone out, you are doing it wrong. Improve.

For ideas with strong potential and decent capital requirements, once you've got the pitch down write a decent investment prospectus document aimed at larger scale institutional investors. Find some and test their reactions. Don't spend too much of your time on the small fries.

For ideas with minimal capital requirements, don't waste time raising just execute and beg/borrow/steal until you get cashflow positive.

</comment><comment><USER6> [https://foundersuite.com/](https://foundersuite.com/)

<comment><AUTHOR> I was considering them - have you used it yourself? I'd like to know more about your experience with it?

</comment></comment><comment><USER7> I've heard good things about funding sage</comment>


Was Apple the first major open-source company? Not even close - <AUTHOR> http://www.zdnet.com/article/apple-was-the-first-major-open-source-company/ <comment><USER2> The key is first major "computer" company.</comment>


It Came from the '70s: The Story of Grandma's Weird Couch - <AUTHOR> https://www.collectorsweekly.com/articles/it-came-from-the-70s-the-story-of-your-grandmas-weird-couch/ <comment><USER2> I have that brown Pyrex casserole dish, shown in picture #23 at the bottom. It was a hand-me-down from my parents for when I left for college. I never had the lid, because it broke long before that.

</comment><comment><USER3> Everything in the 70s was strange. I received a lot of my mother's things when she moved, and it's all avocado and orange.

<comment><USER4> Brady Bunch colors ;)

</comment></comment><comment><USER5> You could buy an awesome muscle car for a few hundred dollars. I had a lot of fun with mine. Cars today aren't any fun.

<comment><USER6> Those grandma couches were $399 in 1977 though (article has catalog with prices).

</comment></comment><comment><USER7> This article brings tears of nostalgia to my eye.</comment>


Eloquent Javascript (ebook) - <AUTHOR> http://eloquentjavascript.net/contents.html

<comment><USER2> Doesn't scroll when viewed using an iPad. You have to use two fingers.</comment>


Tell HN: Driverless trucks: just because we can, doesn't mean we should - <AUTHOR> There are hundreds of thousands of people and families whose livelihood, ability to pay their bills and put food on the table depends on driving trucks.
Just because we can make driverless trucks does not mean we should.
It would be great if sometimes our society made decisions looking to the wellbeing of other people instead of focusing on profit for companies.
What is going to happen to those people and their children who no longer have a means of income?
I feel like technologists corporations and government don't have much ability to put themselves in the shoes of those who aren't doing well financially. <comment><USER2> The system actually has a terrific incentive to block innovation in the autonomous hauling space: avoiding mass unemployment and middle class unrest. Imagine you take away the best way for a person to place themselves squarely in the middle class, then multiply that person's anger by millions.

The benefits are also tremendous though. Those people would be unburdened of repetitive, menial, dangerous work and society would have a more effective and reliable way of transporting goods.

In the end it's about what fulfills more people's needs more effectively. You can't blame a company for trying to find any way of increasing profits, you can't blame governments for trying to protect tax payers, and you can't blame unemployed people for being restless. The question the world has to answer soon: if boosting economic growth and increasing the efficiency of the market are our main goals, what are we willing to do or not do to get there?

<comment><USER3> _> The benefits are also tremendous though. Those people would be unburdened of repetitive, menial, dangerous work and society would have a more effective and reliable way of transporting goods._

Perhaps.

If, and only if, they can get something that at least partially replaces the menial work they lost.

To give a worked example, some of the former mining communities decimated by the pit closures in the 80s are dead communities with unemployment around the 40% mark, to this day. Many people never worked again, despite having spent many years in constant employment and were plagued with depression and other illness as a result of losing career. Many of those former miners would trade the half lifetime of unemployment for repetitive, menial, dangerous work in a heartbeat.

So in that case you're not filling people's needs more effectively, especially when as is so often the case, only lip service is paid to providing alternate options, encouraging industry to move to decimated localities and providing real, substantive help to those unable to find alternate employment.

<comment><USER2> You're right. This is the danger we're facing as automation across industries looms greater. There is reason to be pessimistic, seeing as governments and other institutions have historically dealt with this very poorly. I believe the danger is greater when middle class jobs (according to this site the average starting pay is $40k/yr [http://www.alltrucking.com/faq/first-year- truck-driver-salar...](http://www.alltrucking.com/faq/first-year-truck-driver- salary/)) are tossed in the mill. There are few other alternatives when it comes to salaries like that. A high school graduate is going to have a hard time finding anything remotely close to that kind of pay, and that will be worse in rural working class communities, like the kind you point out.

This discussion is not full without some mention of the basic income debate. That is the leverage point at which governments can make a difference. The problem is that those policies will be difficult to fund at the beginning, before we see the possibly dramatic economic benefits of automation. My other fear is that this reality will cause governments to stifle automation. Things are usually very messy before they get better.

<comment><USER3> My concern is if a basic income is introduced it will be so low as to render it near meaningless.

In the UK minimum wage is around £11k, welfare gives somewhere around £3k I think. A basic income is likely to be nearer a welfare level than a working minimum. Politically I think it's going to be a very tough sell to set it at working minimum. I think it has to be at or near working minimum to be effective.

We're potentially looking at unprecedented numbers of lives ruined unless it is handled better. Nearly all options for manual or lower qualified workers are going away. It probably is going to be very messy.

</comment></comment></comment></comment><comment><USER4> I've never understood this argument. Is it "we should keep inefficiencies in the system, because some people make money off of those inefficiencies"?

<comment><USER5> I understand the argument. Your rephrasing overlooks that our society demands that most people make money to live a decent life, and it's a lot of people making a not-crazy amount of money off the inefficiencies, and it's not obvious what industries could be expected to provide a comparable living to that many people.

That said, I don't think making everyone pay more to ship things so that some people can do something that isn't valuable any longer is the way to go.

</comment></comment><comment><USER6> I'm sure the same has been said of many other sorts of everyday technology that we all find commonplace now.

The machines are coming and there's nothing you can do about it -- adjust and thrive, or don't. It's going to happen either way.

<comment><AUTHOR> It's a real pity that we feel we don't have the ability to make decisions against "the inevitable" where that outcomes aren't good for people and that we should "deal with it".

<comment><USER6> It's not a shame, it's evolution -- we get better at building solutions for things we used to do manually -- it frees us up to focus on things that really matter -- like Angry Birds and whatnot.

</comment></comment></comment><comment><USER7> Yes it absolutely means we should.. at least to avoid the hundreds or thousands of accidents per year caused by truck drivers.

</comment><comment><USER8> I don't see robots taking away flatbed trucking work. The most important part of the job is in the securement of irregular loads (and the adjustment of said securement, as needed, during the trip).

</comment><comment><USER9> BTW, we can make driverless trucks? I keep hearing the same thing about flying cars. For about half a century now, without anything substantial to show for it.

<comment><USER10> Volvo have been trialing driverless trucks for some time now.

[http://www.volvogroup.com/group/global/en- gb/_layouts/CWP.In...](http://www.volvogroup.com/group/global/en- gb/_layouts/CWP.Internet.VolvoCom/NewsItem.aspx?News.ItemId=109685&News.Language=en- gb)

>Volvo's vision of combining a well-trained professional driver with increased automation is being realized through the SARTRE (Safe Road Trains for the Environment) project. The idea behind the project – of which Volvo is a part through its centre for research and innovation, Volvo Technology – is to develop a technology for vehicle platooning – that is, a convoy where a professional driver in a lead vehicle drives a line of other vehicles. Each vehicle in the convoy measures the distance, speed and direction to the car in front, and adjusts accordingly. The vehicles are not physically attached to each other and can leave the procession at any time. But once in the platoon, the following drivers can relax and do other things while the platoon proceeds towards its destination under the expert guidance of the lead driver.

[http://www.independent.co.uk/life-style/gadgets-and- tech/fea...](http://www.independent.co.uk/life-style/gadgets-and- tech/features/autonomous-vehicles-how-safe-are-trucks-without-human- drivers-9047546.html)

> In 2012, Volvo Trucks tried out its autonomous vehicles on public roads for > the first time, as part of the European Commission-backed Project Sartre > (Safe Road Trains for the Environment), which looked at the feasibility of > platooning – when a single, lead driver in a truck, using what might be > thought of as a kind of digital towbar, controls the speed, steering and > braking of two or more trucks or cars, to form a road train.

> Now, the EC has just announced the €5.4m (£4.55m) Project Companion, led by > Scania, to develop the technology further and explore the legislative > changes necessary for this kind of automated road train to run on motorways > such as our own M4. So while talk of Amazon's delivery drones have caught > the headlines, autonomous trucks may be doing precisely that in about 10 > years' time, if the law catches up with the technology.

Video from 2012: [https://www.youtube.com/watch?v=oV3nINN2ELQ](https://www.youtube.com/watch?v=oV3nINN2ELQ)

<comment><USER9> I'm aware of this. What I'm trying to say is that there's a lot of uncertainties and risks in this branch of the tech tree. Just like flying cars, having a prototype here and there does not make this mass usage.

</comment></comment></comment><comment><USER9> Just because we can make horseless carriages does not mean we should.

Oh wait. That gave the livelihood _to_ truckers, so it's Something Completely Different. Right?

</comment><comment><USER11> Deliberately putting your company at a competitive disadvantage goes against what makes capitalism work.

There is time to plan for this change.

</comment><comment><USER12> Well, it's at least a decade away. If you knew your job might disappear in 10 years, couldn't you plan for it?</comment>


Ask HN: Your Thoughts on NYU Courant CS Program - <AUTHOR> For master study. Have to decide whether to go or not recently.
If someone has opinions about the quality of the program, or how its graduates be perceived among tech world, it would be helpful it you can share.
Thanks. <comment><USER2> Depends on what you want to study. Historically it was a very strong compilers school, and when I went there for my undergrad it still had that emphasis, which is not as exciting for the industry anymore. However, just as I was finishing up, they hired Yann LeCun, and after a decade, NYU became a "Deep Learning" power house.</comment>


Ask HN: Help finding python profiling article - <AUTHOR>

Hi I remember reading a blog post someone posted here a year or two ago, about someone profiling his python code and rewriting it to be a lot faster. It had a lot of details of what was done and the <i>reasoning</i> behind it. Does anyone happen to know what it was? <comment><USER2> Maybe this? [http://pymotw.com/2/profile/](http://pymotw.com/2/profile/)

From here: [https://hn.algolia.com/?q=python+profile#!/story/forever/0/p...](https://hn.algolia.com/?q=python+profile#!/story/forever/0/python%20profile)

I use pinboard to bookmark anything that I think has the slightest chance that I'll want to see it again. Most of the time I never look at a bookmark again, because you usually don't know what you'll need in the future. But I've found enough things like what you're looking for (but not this time obviously) that the practice has become worthwhile.

[https://pinboard.in/](https://pinboard.in/)

</comment><comment><USER3> [https://zapier.com/engineering/profiling-python- boss/](https://zapier.com/engineering/profiling-python-boss/)

[https://news.ycombinator.com/item?id=6837034](https://news.ycombinator.com/item?id=6837034)

???

</comment><comment><USER4> I usually turn garbage collection off, and then explicitly call it just in places where I need to free up memory. I get a modest 5-10% speed boost from that alone.

Another trick is to look at your innermost loops, and make sure you aren't doing accessing anything fancier than a variable.

Example

Bad:

for i in onemillionthings: for j in onemillionotherthings: print SomeClass.otherthing.A

Better: tempvar=SomeClass.otherthing.A for i in onemillionthings: for j in onemillionotherthings: print tempvar

</comment><comment><AUTHOR> It isn't the ones listed so far. I vaguely remember it talking about choices like loops, comprehensions, data types etc. and eventually his code became about 8-10 times faster.

I will continue to search and will post back here once I find it. Thanks for everyone's help.

</comment><comment><USER5> python profiling site:news.ycombinator.com

???

<comment><AUTHOR> that's the search I used, but couldn't find it</comment></comment>


2011 Cloud M&A Predictions - <AUTHOR> http://www.ricmerrifield.com/2011/01/2011-cloud-ma-predictions/

<comment><USER2> There are so many things wrong with this.

1) Symantec is a 13 billion dollar company. They will not be easily picked up. They have the cash to acquire every other company on your list.

2) There is not a single company on your list that people would consider to be a cloud company. They are Internet companies. They are not multi-tenant, SaaS, cloud computing, etc. They are websites, software companies or technologies. SYMC has some cloud services, but that might be the exception. Yelp, Doxo, Tippr, Gist, etc. are not even close.

</comment><comment><USER3> How many of these are actually "Cloud" companies?

<comment><USER4> Ya, was going to say the same thing... Do we just consider these web apps or SaaS?

I was thinking this would be like an analysis about how Rackspace would buy Linode and slicehost or something. (not saying that as a reality)

<comment><USER5> I stopped reading the article as soon as I saw Yelp has the target acquirer Netflix??

</comment></comment></comment><comment><AUTHOR> Was really going off the recent Merrill Lynch report on internet trends and following their categorizations within the cloud space. Yes, I include SaaS apps under the umbrella term cloud. In some areas it's just a new label for things the existed, but that's not the case with everything in the cloud space.

</comment><comment><USER6> I like how the 8) on the eighth item in the list is translated into a smiley face. It's a nice touch.</comment>


Show HN: A collective list of APIs – apilist.fun - <AUTHOR> https://docs.google.com/spreadsheets/d/19T9WUgWBrL9Ej3XUoA2rXSqYDbHa966IPtqpzRup-_k/edit#gid=0 <comment><USER2> This is so heartwarming, it brought a smile to my face as soon as I realized it was a numbers spread. I'll tell you it was an upsetting day, the day I realized all my projects and ideas--software and hardware, whatever--could be reduced down to a database or spreadsheet. Thoughts of, "If only there were a more engaging, fulfilling way to access that data...", or "It's all there; why complicate it!", and "Someone's already done it." only disserviced my already murky disposition. Anyway, you have a list of APIs, but in the spirit of ironic humor, I have to ask: Do you have a way to consume, access etc. this list? Does G-Sheets offer that inherently?</comment>


Compile Ruby into WebAssembly - <AUTHOR> https://github.com/jasoncharnes/run.rb <comment><USER2> I'm a little confused by this. Did someone manage to write a YARV to WASM compiler? I kind of doubt this is a wholly new Ruby to WASM compiler, so my best guess would be a YARV to WASM compiler. Except...even that would be tricky since Ruby has a notoriously complicated runtime. Just looking at this though, it looks like they just compiled an existing Ruby implementation to WASM via Emscripten. But that's not really compiling Ruby to WASM then...

<comment><USER3> Yeah, look like it is compiling Ruby (the interpreter, aka MRI or CRuby), not programs written in the language Ruby.

<comment><USER4> So , the maximum you can get from it is the console log text return of the script you paste there. right? Or you can glue your script with anything like webgl or canvas there to do anything?

<comment><USER5> WASM doesn't provide DOM access so you can't use anything useful on the web unless you callback through a bunch of JS.

<comment><USER6> I imagine that is some sort of intentional sandboxing? I didn't know about that and find myself surprised. In principal I'm not sure why it wouldn't be able to provide direct DOM access. I'd love to hear more background on this if you know it.

<comment><USER7> It's coming: [https://github.com/WebAssembly/host- bindings/blob/master/pro...](https://github.com/WebAssembly/host- bindings/blob/master/proposals/host-bindings/Overview.md)

</comment></comment></comment></comment></comment></comment><comment><USER8> I'm proud that this project's Dockerfile bases on mine :D Didn't expect it will be used widely.</comment>


Five Ways the Tech Industry Can Lead During the Trump Era - <AUTHOR> https://backchannel.com/the-tech-industry-can-and-should-lead-in-the-trump-era-378f9d35331c#.e2bp3jtru <comment><USER2> Point #1 is essentially the 10th Amendment.

If you want more choice, more ability to iterate quickly and experiment with different ideas, this has to happen at the local level. If you defer it to the national level, you get things like no child left behind and common core. These may be good for some parts of the country, but are they good for all parts of the country?</comment>


We made something that at least one person really wanted. - <AUTHOR>

<comment><AUTHOR> <http://www.xanga.com/FightToDeath>

Collin is a user of likebetter.com. Maybe this won't tickle others as much as it does me, but just LOOK at how we've basically given this guy a purpose in life. Seriously, he's creating a whole world around likebetter.com.</comment>


Boeing Engineers Lost Control of the Company - <AUTHOR> https://www.perell.com/blog/boeing-737-max <comment><USER3> > Why did Boeing buy McDonnell-Douglas? Because the airplane manufacturing > industry is consolidating, and Boeing is pursuing profit at the expense of > human lives.

Was it really necessary to add the second part to explain why the merger occured? 'industry is consolidating' seems reason enough. The mixing of explanation with moralism in every sentence is grating. Put the moralism and ethics in it's own paragraph so we can understand the explanation first. If it's all mixed up, then I have to evaluate every claim in the article as if it might be ethical statements by the author instead of focusing on understanding first, and then considering the ethical outcome after having attained the understanding.

<comment><USER4> It's a hyperbolic statement. Boeing employees and engineers also fly on those planes with their families. It isn't like they are making decisions with the intent of compromising safety.

<comment><USER5> Boeing executive decision makers don't. They never fly commercial, they have private jets.

<comment><USER6> Interesting side note, Boeing does make private jets - the Boeing Business Jet family[0].

But Boeing executives doesn't fly on these, since they're too large for even CEOs. Boeing executives fly on one of the three Boeing owned Bombardier Challenger 650s [1][2][3].

[0] [https://en.wikipedia.org/wiki/Boeing_Business_Jet](https://en.wikipedia.org/wiki/Boeing_Business_Jet)

[1] [https://www.planelogger.com/Aircraft/Registration/N541BA/908...](https://www.planelogger.com/Aircraft/Registration/N541BA/908966)

[2] [https://www.planelogger.com/Aircraft/Registration/N543BA/908...](https://www.planelogger.com/Aircraft/Registration/N543BA/908968)

[3] [https://www.planelogger.com/Aircraft/Registration/N544BA/884...](https://www.planelogger.com/Aircraft/Registration/N544BA/884121)

<comment><USER7> Former CEO James McNerney used to fly in the BBJ all the time. Sometimes he was the only passenger.

</comment></comment></comment></comment></comment><comment><USER8> Note two contradictory popular trends: 1\. AI is going to replace cheap labor 2\. Engineering companies are outsourcing because of cheap labor

The reality is that trend #2 is orders of magnitude larger. Any reversal of that by 'AI' would be the biggest jobs boom in decades for western nations, and according to this article, would increase quality and therefore trade balance as well.

The other reality is that manufacturing automation with 'AI' is hard, takes a lot of human effort, and is a huge part of a company's value (e.g. Tesla). Outsourcing is often selling off this value at a negative price. It is done because Wall St analysts don't know how to price this asset.

Like it or love it, it is investment analysts that determine company culture. The good thing is that they are greedy; they may be misinformed, but they are predictable. Everything above liquidation value is held in the heads of the employees of the company. Its actually not that hard to compute, and if business schools taught this, corporate behavior would change.

<comment><USER9> Unless you look at long term focused companies like Amazon, which is creating all kinds of value without bowing down to short term market analysts. Had Boeing looked beyond the immediate future and planned to upgrade the 737 frame, or make a new one so it could support the much larger engines, they wouldn't be in this situation. But short term costs and profits, outsourcing and negligence is running the company. Break them up until the have some competency in what they are doing.

<comment><USER8> Amazon is a case of purposely cultivating long-term investors and analysts. Somehow they made a case that their intangible NPV is much larger than other companies with similar profits. However, history indicates that a CFO will soon take over, start outsourcing, and they will be more profitable, but their long-term investors will sell to short-term investors and give them short-term valuations (lower NPV).

<comment><USER9> Jeff would never give up any control, at least not until there are O'neil cylinders in orbit.

<comment><USER10> He is selling Amazon stock every year to fund Blue Origin. I sure hope he can start turning a profit on his space company and gets his O'Neill cylinders before he runs out of cash.

</comment></comment></comment></comment></comment><comment><USER11> While I appreciate the amount of effort the author put into writing this, Matt Stoller's analysis of the Boeing situation remains the best I've found so far: [https://mattstoller.substack.com/p/the-coming-boeing- bailout](https://mattstoller.substack.com/p/the-coming-boeing-bailout)

<comment><USER12> This is short and excellent. Thanks for sharing.

I wish Mr. Stoller took more time on this:

> The Federal Aviation Administration, having outsourced much of its own > regulatory capacity to Boeing, didn't know what was going on, and Boeing > didn't tell airlines and pilots about the new and crucial safety procedures.

This seems like big deal to me.

<comment><USER13> Indeed. Meet _accidentology_ , "the study and analysis of the causes and effects of accidents", which became a huge applied field during the second half of the 20th century — notably driven by air traffic (also championned by medical care among other sectors).

The gist of it is extremely simple: most fatal accidents happen because of a _sum_ of mistakes, a _chain_ of more or less important errors which, taken individually, would seldom lead to an accident, but together form "the perfect storm". This is btw the true meaning of Murphy's famous quote (especially the 'worst possible time' part, e.g. software failing in-flight as opposed to during tests), and how we avoid such outcomes.

The beauty of accidentology, beyond engineering / repairing honesty, beyond tons of carefully written procedures and double checklists, is also quite simple: to systematically track the origin of mistakes, to reward people who were involved in finding the issue, and fix the problem once and for all through better practice, better documentation, changing procedures.

It contributed to make air travel statistically the safest means of transportation for human beings (the rationale was that plane crashes were so traumatising to the general public that it wasn't enough to be "better" than cars or trains or ferrys; air travel had to be 99.99...% safe to succeed).

In this case, we indeed have multiple failures which form a chain of events: the manufacturer (Boeing) cutting corners on safety, the regulator (FAA) also cutting corners in what looks like plain and simple corruption here, and somehow everyone else (companies, pilots) taking for granted what Boeing/FAA said. All in the name of more profit, for a ridiculously tiny part of the population. The results are the tragedies we witnessed. And while the first crash should have been a wake-up call, the fact that Boeing themselves didn't come forward and did let a second crash occur is borderline criminal (for courts to decide, anyway, but the question seems salient in this case).

It's all extremely worrying and sets a dire precedent for the USA as a lax or incompetent regulator, and a champion of big corporations now apparently digging way too far down the 'profit hole' — it has literally become a grave by that point.

</comment></comment></comment><comment><USER14> > In the case of information technology-related manufacturing, research, > development, and marketing are the most profitable areas to specialize. > Fabricating the units and linking critical components is a low-margin race > to the bottom. Inspired by this theory, companies like Boeing aim to > specialize in high-margin activities and outsource the rest.

This is the core point which the author seems to be trying to make, that outsourcing necessarily raised costs because it's a de facto defective strategy for improving margins. What the author fails to delve into is precisely why subcontracting failed to deliver as imagined - <USER2> subcontractors fail to deliver airplane parts within tolerances? Were the specifications provided to subcontractors faulty? Did the outsourcing contracts fail to require compensation for failing to deliver on-time and within tolerances; did such requirements exist but in reality such financial obligations caused subcontractors to run out of money / go bankrupt and default on their obligations? Was no insurance purchased to hedge against these risks, so that costs would not explode along with delays?

Part of smile theory is that when you decide to outsource lower-margin operations, the ability to outsource effectively in and of itself becomes part of your core competency. That Boeing executives failed to reduce costs as planned through outsourcing is less proof that outsourcing is inherently poor practice and more proof that competency at shifting numbers around on bean- counting accounting sheets is not the same thing as competency at outsourcing.

<comment><USER8> There are different kinds of outsourcing. One is where a subcontractor has an existing and superior product, which incurs integration cost, but results in a superior product. The other is exporting a core competence to an inexperienced subcontractor for less cost, which incurs training costs, integration costs, loss of intellectual capital, logistics loss, and results in an inferior product.

<comment><USER14> > which incurs training costs, integration costs, loss of intellectual > capital, logistics loss, and results in an inferior product

What I'm arguing is that, in order to effectively outsource, one must get good at the so-referred training and integration costs, while hedging against logistics issues. Otherwise you will get, as you prophesy, an inferior product. But I'm not convinced that's inevitable.

Of note, keeping everything in-house can result in its own logistics issues, as the organization becomes necessarily larger and must pay related overhead costs. So deciding to keep processes in-house doesn't mean you get to completely ignore "logistics loss" because you're paying a similar price in its stead.

<comment><USER15> > What I'm arguing is that, in order to effectively outsource, one must get > good at the so-referred training and integration costs, while hedging > against logistics issues

I think by now we have demonstrated that this is false, no? In the 1960s, it was a popular idea (especially among managers) to assume that a company can have a core competency of "management" rather than making products or services. If true, such a core competency would mean

1) You can take a great manager at an Ice Cream making company and move him over to an Aerospace company and he'd still be a great manager.

2) Rather than being facilitators who helped to coordinate talented people, managers had their own talent at "managing" and so you can pay them the kind of superstar wages that were previously paid to superstar performers.

3) The above two skills could be efficiently measured and identified to allow scaling them to a large organization.

This idea was obviously very popular, and so a business structure called the "conglomerate" arose where one huge company would buy and own many different smaller companies all with completely different product lines, because the competitive advantage of the conglomerate was viewed to be "managing" rather than producing, and thus the superior managers would improve margins at pretty much anything they were put in charge of.

But unfortunately what ended up happening was that the conglomerates underperformed. There are still some conglomerate hold outs, like Berkshire Hathaway, but everyone knows that this is because of Buffet's investment acumen, not because Berkshire has a stable of excellent managers. Perhaps there is such a thing as pure "management" skill, rather than say, "Engineering Management", but if such a skill exists, it's sufficiently difficult to measure and/or replicate from one product area to another that none of the businesses who thought they had this skill as a core competency actually had it. This remains the case today -- there are many well managed companies, and many talented managers, but 'management' has never been and cannot be a core competency of any firm.

So this idea that Boeing can shed its core competency from building planes and replace it with a "coordination" core competency is a rehash of the conglomerate dream with the same disastrous outcomes, and many people who saw what Boeing was doing knew exactly what this would lead to.

<comment><USER14> > it was a popular idea (especially among managers) to assume that a company > can have a core competency of "management" rather than making products or > services.

No, that isn't the argument at all. A manager at an ice cream factory doesn't need to understand aircraft manufacturing tolerances. If a manager at an ice cream factory outsources the production of chocolate, and the chocolate that arrives as an input is slightly off-grade, it's not going to cause thousands of tons of aluminum and human flesh to come crashing out of the sky.

Risk management has its similarities across disciplines, just as the principles of Lean Manufacturing are similar across disciplines. But you can't effectively outsource something you don't intimately understand, which (by the way) is why it's impossible to outsource research.

<comment><USER15> I guess I don't understand your point. First, you say "that's not the argument", but then you make the case that Ice Cream production is qualitatively different. Yes, exactly! You don't have the depth of the supply chain or the level of interconnectedness in the ice cream factory as you do when you are building a jet with pieces outsourced that are moving parts that need to work together. A slight flaw in the wing tip will change the stresses on the plane, the fuel efficiency, will require software updates, and will trigger changes throughout many other components. Now change that from "flaw" to unknown factor. In that environment, it's really impossible to specify what the tolerances on everything should be in full precision, you need a team of people with a common purpose and short communication paths who can collaborate on fixing these issues in a cooperative manner rather than in a contractual vendor/supplier relationship. E.g. if there is a problem discovered in the design, perhaps you need some changes in the wingtip design and in 1000 other parts, and everyone needs to work together to make that change. Now, what happens when these are 1000 different companies working to spec, with lots of lawyers poring over the details of what was required. It becomes an unworkable nightmare. Only a true coordination talent with heavy doses of prescience could try to solve that nightmare, Boeing thought they had this coordination talent, but they didn't because no one does.

Such a talent is not a core competency of any firm.

More importantly, such a manufacturing process is incompatible with innovation, where you have to be able to make lots of mistakes as you stumble towards a better design iteratively. It only works when everything is known to spec before the contracts are signed -- e.g. when you are _not_ innovating.

This type of design agility can't be extracted from the minds of conscientious engineers working together on a shared vision, and parceled out to for profit contractors looking to do spec work.

Similarly risk management certainly adopts a common language, but the idea that you can actually manage risk in a quantitative way is not something borne out by experience. Rather, you can cover your a$$ and say you have sign off from you GRC people so that when stuff breaks down you can point the finger at someone. We just exited a massive financial crisis, and we see security breaches on a massive scale, most of which happen in firms with well funded GRC teams. Again, wishing that you can control these variables does not make it so. Putting together a bureaucracy to control something doesn't mean that it's controlled.

<comment><USER14> > Such a talent is not a core competency of any firm

No it's not, which is why agile processes have less risk than waterfall processes. You're not making the argument that Boeing should keep all of their manufacturing in-house, you're explaining why Shenzhen has become the hardware manufacturing capital of the world. Shenzhen isn't controlled by a single company, and the ability to quickly order parts from other manufacturers in the Shenzhen area allows hardware manufacturers to respond with the agility you describe. Who controls the individual manufacturing processes is less important than the speed of the feedback loops.

> the idea that you can actually manage risk in a quantitative way is not > something borne out by experience

Well, Wall Street would disagree with you.

> We just exited a massive financial crisis

2008 happened not because the underlying risk models were wrong but because people were sold high-risk instruments on the fraudulent premise that they had almost no risk at all, and the rating agencies which mislabeled the risk hid behind the First Amendment. If the high-risk instruments were honestly represented at sale, they wouldn't have been purchased by people seeking low- risk instruments, and the portfolios of most market players would've been well-diversified as planned and able to withstand those kinds of shocks. That the rating agencies were able to hide behind the First Amendment (risk assessments are not political speech) and that nobody went to jail for the fraudulent risk assessments remains a great injustice, in my opinion.

> we see security breaches on a massive scale

Because law and regulation do not set sufficient financial penalty for insufficient security practice and the market at large has shown not to care enough about security to punish players with poor security practice, so the financial risk of a breach is (in my opinion, unacceptably) too low to cause a change in corporate behavior. Again, not an issue with risk management, just people responding to systems as designed.

> Putting together a bureaucracy to control something doesn't mean that it's > controlled.

Sadly I actually agree with you on this, which is why I wrote, and I quote, "competency at shifting numbers around on bean-counting accounting sheets is not the same thing as competency at outsourcing".

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> You see this at startups too, middle eng management were actual engineers and as the startup grows career managers creep in and skew the alignment of the engineering departments away from engineering solutions, the "product" they make, to problems they understand instead, political jockeying, manipulation, appeasing the LCD and the next managerial rung above them.

<comment><USER17> Your initial scenario is still flawed: "middle eng management were actual engineers." The problem is elevating management above other roles. At that point the course has been set.

<comment><USER18> And they may know how to manage devs but they have very little change of being good at , which is what protects the dev team.

When the smooth talking suits show up and tell their pretty dictions, there aren't enough people who know how to push back.

But where would you find these classically trained managers who haven't drunk the Taylor koolaid?

</comment></comment></comment><comment><USER19> I don't flag articles but this is one that I would flag. Why? It's typical HN 'red meat'. Well presented and (seemingly) well written and thoughtful. But the writer not only has no expertise (he did research?) but offers no backup (other than things that other news outlets have written) for most if not all of his statements. Now it's on thing if you are a major news outlet (NYT, WSJ or online well know publication) and it's another thing if you are just 'some guy, writer with a 'media company'' (what he does) and you do this and post your own articles.

[https://news.ycombinator.com/submitted?id=davidperell](https://news.ycombinator.com/submitted?id=davidperell)

Why bother to read this exactly? There is always a question of what you read being true and sure it's fun to poke positive or negative. But honestly having a flashy website or blog is not enough.

(Kudos David for being opportunistic (I really mean that btw) pulling this off).

<comment><USER20> Couldn't agree more. This is a rambling mess of an article which strings together past commentary on Boeing's history and the 737 Max without making a coherent point.

Furthermore, the author also gets a number of things wrong about his research, and also presents statements as pure fact which are purely false.

Here are three examples I pulled out—in order from minor to argument- disqualifying.

1\. The author cites innovation on the 787 as having electrically operated systems in place of hydraulics. He meant to say pneumatics. The 787 does not have an engine air-bleed system, using solid state electric systems to power the aforementioned components instead of the system of valves and ducts which manage the flow of high pressure air coming off the engine, as is the norm on other aircraft.

2\. The author sites engines being outsourced historically because of a natural difference in engineering expertise between engine and airframe. While engine and airframe engineering are different domains, the real reason airframe manufacturers don't make engines and vise-versa is entirely due to the Air Mail Act of 1934. I suggest the OP research the United Aircraft and Transport Corporation.

3\. The OP's central argument of cost control, and particularly outsourcing, as being a central driver to engineering problems with the MAX is hindered when he cites example and supporting arguments primarily about the 787 program.

Yes, cost control is an overarching issue and one that is being investigated vigorously, and 787's level of airframe outsourcing has been a key problem to that particular program's profitability.

However, the author fails to understand that the outsourcing he talks about is made at the program level. Citing the 787 as being representative of Boeing as a whole is spurious. The author also fails to understand how outsourcing effects engineering both at Boeing and down the supply chain.

In truth, the level of outsourcing on the MAX is largely no different than on the NG. (The previous model 737 that has been flying safely for decades, which went into service 2 years before the MD-Boeing merger.) It has been common since the advent of the jet age for there to be separate suppliers for engines and components—i.e landing gear or avionics. This does not mean innovation and engineering expertise is past over the fence—-airplanes are in fact built on strong partnerships between firms, and that includes partnerships between engineers. This has always been how the industry works.

Now, tying this back to my 3rd example: The 787 supply chain problems the OP sites are in regards to final assembly of fuselage and wing structures — this is a specific area in which one could argue the 787 went overboard in outsourcing. This, of course, has nothing to do with MCAS—a piece of flight control software—nor the AOA vanes that feed it. Flight control systems, sensors, and vanes are typically outsourced, as they are on the 777, 767, 777, and 747 (all of which engineered and built before the merger.)

...

If we really want to add value to the conversation about Boeing's culture, the 737 MAX, and engineering aircraft—then let's please build some knowledge first about how aircraft systems are actually engineered.

Disclaiming that nothing can be definitively said about the MCAS crashes until all the investigations are complete and known, I strongly believe the issue is not a software failure but a systems failure, and particularly, a failure in the management of the safety classification and assessment process.

There is also the matter that the 737 is a very old program. Beyond the argument that it was a mistake to try to modernize a 1967 design and architecture a 3rd time, there is also the problem that the 737MAX doesn't necessarily adhere to current engineering standards for safety assessment—especially at the systems level. This is because the 737MAX was engineered under the authority of the original 737 certification.

For aerospace engineers working in industry, it would be useful to map what we know about MCAS and the 737MAX against the requirements outlined in DO-178C and, especially, ARP-4754. Unfortunately, the 737MAX doesn't subscribe fully to ARP-4754 methodology, since it's a continuation of the program certified in 1967 and not a new type.

</comment></comment><comment><USER21> So exactly the situation that Steve Jobs describes in his infamous interview on how sales and marketing takes over product focused companies.

<comment><USER22> What makes the interview infamous? Did you mean famous?

<comment><USER23> I suppose its infamous amongst sales and marketing folks.

<comment><USER24> I would point out that there are very few sales and marketing folks reading hackernews vs engineers and scientists and coders.

</comment></comment></comment></comment><comment><USER25> I don't understand how this was a software failure. From everything I've ever read about this issue, including this piece, the failure seems very much like a model & design failure.

It seems like a systems & human factors engineering failure. Not a software failure.

<comment><USER26> There were absolutely software design failures - to have two sensors but only read the value of one of them and to not even apply sanity checks to check the sensor is working (e.g. is the sensor saying that the aircraft is pointing towards the sky when it's on the ground?).

It's simply crazy. The only plausible explanation is that Boeing did not perceive MCAS to be safety critical, even though it had control of the aircraft, and so they didn't bother to apply any redundancy to it. Boeing seemed to wrongly assume that any failure modes would appear as a runaway trim.

<comment><USER25> That seems very specifically to be a design failure, not a software failure, no?

</comment></comment></comment><comment><USER27> _> To this day, industry insiders still joke, "McDonnell Douglas bought Boeing with Boeing's money."_

That's commonly said about the Apple-NeXT acquisition too — NeXT paid a negative $429 million to take over Apple.

Obviously the results were much different there...

<comment><USER28> > > To this day, industry insiders still joke, "McDonnell Douglas bought > Boeing with Boeing's money."

> That's commonly said about the Apple-NeXT acquisition too — NeXT paid a > negative $429 million to take over Apple. (...)

I guess that is why it is considered a joke. It sounds like the management teams of NeXT / McDonnell Douglas benefited much more (in the long term) than the investors of their defunct, purchased companies. Benefiting through greater compensation and clout without really taking over (i.e. owning) the purchasor's company.

</comment></comment><comment><USER29> Happens every time the accountants and MBA's take over. Experience with three companies bought out by investment funds/accountants. Move on as quickly as possible. Cheers

</comment><comment><USER30> My own personal (fanciful) beliefs:

\- at least two executives including the CEO should get life in prison

\- at least two people from the FAA should join them

\- Boeing should be dismantled and become at least two separate companies.

\- The FAA should also be rebuilt from the ground up.

\- Create a new type of corporate tax that helps ensure the FAA has a more adequate budget.

\- New law that ensures that CEO and some other upper-level decision makers need to have senior engineering experience. (Ideally there would be no executives at all, just engineers, but that's too unrealistic even for my fantasy here).

</comment><comment><USER31> > The new engines were too big to fit in their traditional spot under the > wings. To combat the problem, Boeing mounted them forward on the wings. > Moving the engine position forward shifted the plane's center of gravity, > which altered the aerodynamics of the aircraft. The position of the new > engines pulled the 737 tail down, pushed its nose up, and put it at risk of > stalling.

Can someone explain to me how this is possible? In my understanding If you move the engines forward, it would move the center of gravity forward as well, and this would push the tail up and pull the nose down - exactly the opposite from what's written in the article. Does some fancy aerodynamic effect play some role here that leads to stalling?

<comment><USER32> Layman here. What I picture in my head is due to the engines being placed higher and more forward on the wing, it will want to rotate nose up when thrust is being produced.

<comment><USER33> This is correct, and normal behavior actually. That's already accomodated for in modern designs.

What isn't is the extra lift at high-AoA and longer lever arm for the lift force to operate through. MCAS was meant to counter that, and arguably would have been a perfectly reasonable fix if they'd have designed it to the proper degree of redundancy, and actually told pilots how it worked and that it existed.

</comment></comment></comment><comment><USER34> I've often felt GE and other industrial conglomerates have similar issues as those brought up in the article. Too much focus on quarterly profits and investor payouts, obsession over stock prices and "wall street" metrics. Everyone talks about Japan or China stealing our industrial base but it often feels like we did it ourselves.

</comment><comment><USER35> Interesting read, but most of the article is about the increased costs of outsourcing of component fabrication. It doesn't really explain how the MCAS system evolved, or the outsourcing on the software side, even though the author identifies a software failure as the primary source of the crashes.

</comment><comment><USER36> Has anyone considered that the MCAS bug was just simply nasty and difficult to detect in their simulator?

It's easy to look back with retrospect and make sweeping judgements about the entire company and the FAA.

But fundamentally this was all over, as the author mentions, a single software bug and a lack of backup sensors to offset the risk.

In addition it was the technical pilots who asked for the stick to be harder than it was, which added to the difficulty in that unique situation.

The MAX was otherwise a very safe plane was it not?

There will always be limits to how effective regulatory oversight can be.

<comment><USER37> It also relied on a the pilot as a critical control - which is why there was no real automated backup or redundancy.

Not unreasonable, doing stab trim cutout is a memory item for most operating manuals - pilots were already the circuit breaker for other stab trim issues.

Automation working - great. Maintenance failures? Provide error messages (which occured here). Maintenance issues not resolved and automation misbehevior? Stab trim cutout memory item.

Despite all the claims that the stab trim cutout did not work all real evidence is that it did. Other issues around pressure on flight surfaces not explored properly making recovery in overspeed and other conditions very hard.

Badly designed system? Definitely. Brittle when facing poor maintenance? Clearly! Not taking into account broad pilot population. Of course. Definitely should be fixed, and frankly automation probably will be increased to decrease assumptions around pilot behavior which can be variable.

This accident was the result not only of this bug but a chain of issues. That's why flying in the US is pretty safe, the chain from procurement to maintenance to pilot training is strong so compensates for poor elements.

If you follow SAA technical for example there is evidence overseas that bogus parts are making it into plane repairs, with predictably bad results. We are not seeing that in the US (yet), though if inspections get soft I'm sure it would show up here too. Those bogus repairs will mean that some automation will break and the plane may not behave properly in ways that could have been designed around with better assumptions.

My prediction? We are going to get iphone style authentication / serial number chips in key plane parts with electrical connections and the plane will eventually refuse to fly without the right parts - just like your coffee maker and iphone. Right now it is trust based.

<comment><USER38> s/This accident/These accidents/

As you'll find in this article below, Boeing specifically removed the yoke- back function, which is the natural pilot input to nose up the plane. They also specifically for the MAX removed the separate switch for automatic stab trim assistance, so you have to turn off the motorized function entirely to turn off automated inputs including MCAS. The Lion Air crew could be heard on the radio saying that they did disable the stab trim, but in this situation the force required on the manual trim wheel was beyond the pilots' strength. The pilots turned the electronic stab trim back on in hopes of using the powered system to get back up, after which the undocumented and unstoppable MCAS nosed down the plane again, killing them and their passengers.

[https://www.seattletimes.com/business/boeing- aerospace/boein...](https://www.seattletimes.com/business/boeing- aerospace/boeings-emergency-procedure-for-737-max-may-have-failed-on- ethiopian-flight/?amp=1)

Your post reads like a sophisticated attempt to blame the victims, or at least the pilots and ground crews of the victims. These crashes were not caused by poor pilots, but rather secrets on top of secrets, all by Boeing, all for money.

The MAX had new aerodynamic characteristics, but that needed to be a secret.

So MCAS was added to the electronic trim assistance to hide the new characteristics, and the switch to disable it was removed to protect the secret.

A faulty AOA sensor was now able to bring down the plane, but in order to keep the secret the single AOA option was still available and sold. Maintenance crews regardless of quality would not have been aware of the criticality of the AOA's secret role as a single point of failure for the whole plane.

When the first one crashed, secrets covered it up.

When the second one crashed, it still took all of those "ppor maintenance", "broad quality" non-US airlines and regulators to bring a stop to it.

And apparently the secret-keepers are still trying to hide.

Please don't blame dead pilots for this.

<comment><USER33> One more thing, the flight computer was eventually found to be a single point of failure after being subjected to testing that should have been done in the first place.

[https://www.seattletimes.com/business/boeing- aerospace/newly...](https://www.seattletimes.com/business/boeing- aerospace/newly-stringent-faa-tests-spur-a-fundamental-software-redesign- of-737-max-flight-controls/)

Another regulatory no-no that wasn't brought up until the certified aircraft had been out in the wild long enough to kill people.

<comment><USER37> Is this the five independent bit flips in worst possible order and combination from _cosmic rays_ failure?

First -> if this is your worst failure mode (ie, worse than pilot error, mechanical fatigue and failure, engine failures, fueling issues, crazy passengers etc) then you have a plane and overall safety system that is incredible.

Second -> this wild set of events again does not crash the plane - though it would put the pilots in a bad spot similar to the existing MCAS issues.

<comment><USER33> >First -> if this is your worst failure mode (ie, worse than pilot error, mechanical fatigue and failure, engine failures, fueling issues, crazy passengers etc) then you have a plane and overall safety system that is incredible.

Or would be, if it didn't violate design constraints that demand no single point of failure can have the capability to result in loss of the aircraft. I.e. components with failure profiles of catastrophic severity _MUST_ have redundancy. You test the least likely events to ensure you have sufficient fault tolerance for that very reason.

>Second -> this wild set of events again does not crash the plane - though it would put the pilots in a bad spot similar to the existing MCAS issues.

Actually, one of the three test pilots did in fact lose the plane in the simulator. Hence the reclassification of the flight computer as a component with a catastrophic failure potential.

Look, I'm about the last person you're going to get to buy into the awesome safety of an aircraft that can't even pass a textbook test case for computing in adverse environments. If the bloody thing was so safe and high quality, it wouldn't have been able to suffer that induced failure in the first place. It would have been designed out. The fact Boeing was caught off guard by that failure means they weren't looking very hard, and were banking that no one else would either. Which is generally a really bad assumption to make, because Murphy finds a way. Every time.

<comment><USER37> There's lots of potential for failure that the planes allow when flying.

Some quick examples - they could have sensors around gas quality but do not - they rely on the folks providing the avgas to have good fuel. They could do built in weight and balance calcs with sensors - they do not, they rely on poor estimates for that. etc.

Boeing in particular ALLOWS pilots to fly planes outside of most flight envelope limits. They do this in part because historically they didn't trust the computer as much and trusted pilots more.

Airbus by contrast doesn't let you do this unless you take air data totally offline or something crazy to force alternative law. I suspect boeing will be moving towards the airbus model which is probably right. Airbus had arguably less local myopia when designing their planes - ie, future pilot populations come from a big group and making the plane as error proof as possible is best. Airbus had some issues around their automation without pilot override initially but I think those are resolved by now.

If you want a scary video - check out this early A320 flying - first fly by wire / autothrottle:

[https://www.youtube.com/watch?v=YAg- WauGrLU](https://www.youtube.com/watch?v=YAg-WauGrLU)

Can't have been a good feeling as that pilot. Note that the A320 is now considered a very safe plane.

Aircraft have evolved from systems with almost no built in redundancy or safety. The design of the 737 is pretty old - 1967 or so. Let that sink in for a bit, consider what type of tech they had back in. This is not a 777 generation plane or even A320.

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> MBAs ruining everything again, this is so familiar it ain't even funny. Putting business guys at the top is one of the biggest mistakes in companies, even if we concede that they are needed they should have very limited power not the control of the company like today's CEOs.

</comment><comment><USER40> Engineers create value, management is a tax on that value. And when management takes over a company culture the next stop is typically bankruptcy as management wont stop until all value is extracted into their pockets. American corporate history is littered with examples.

</comment><comment><USER41> Reminds me of what a Steve Jobs warned about marketing people taking over and product people being pushed out:

[https://m.youtube.com/watch?v=-AxZofbMGpM](https://m.youtube.com/watch?v=-AxZofbMGpM)

</comment><comment><USER42> While it is nice to think that this is all a beancounter fault, and to an extent it is, there must be an engineer in Boeing who was tasked with this difficult and challenging mission how to avoid the expensive recertification of the airplane. They must have spent many sleepless nights thinking how to make that happen, until finally reaching a eurika! moment. And I want to believe that they thought the solution they proposed was both sound and economical, yet the execution was lacking. In the end there must be an engineer behind every feature, even if they were pressured by non engineering manager to compromise.

</comment><comment><USER43> When the 737 was first created, iterating a known type of aircraft was much less of a concern. It was not a key design constraint.

As time went by and we learned more and the good idea faeries had time to think about things, we now have all kinds of regulation that makes the cost of making a new plane much higher if it is not an iteration on an existing design.

This sort of regulatory pressure has a tendency to nix innovation in favor of stability, and that's what we see here.

<comment><USER44> I don't think this is a new phenomena. My understanding is that the MD-80 was built on the DC-9 airframe partially to avoid the costs and efforts of recertification, and that was 40 years ago.

Aside from regulation, There are very good business reasons from both ends of the industry that exert pressure to iterate on an old design. (E.g Each additional airframe dramatically increases the complexity of an airline's maintenance organization.)

</comment></comment><comment><USER45> Didn't get to read the full article, but it sounds like a case of snakes in suits. Did the leaders and managers in charge at the time the poor engineering took place get any sort of reprimanding or blame, or have they walked away with accolades of their quarterly performance and cost savings with continued increases in salaries and public reputation?

</comment><comment><USER46> People forget the other purpose of outsourcing which is that it diffuses complaints from other countries that they are buying planes from dupolists and should do something about it because sweden, japan, and other countries that might develop and aircraft industry can point to some part of every Airbus and Boeing made in their country.

</comment><comment><USER47> Why are the engineers being blamed? Why not frame it as

Boeing MBAs took over the company and drove quality down.

</comment><comment><USER48> I agree 100%. McDonnell-Douglas' corrupt military contractor culture ate Boeing from the inside. I have family that work at Boeing and the tales of corruption they told me are hair-raising.

</comment><comment><USER49> I read this article [0] about a month ago that went through what happened to Boeing after the MD merge. After reading it I went through some other articles comparing the development of the 777 to the 787 (the first plane to be designed with this new Boeing management completely in control) and it's staggering how Boeing went downhill from an engineering-focused company perspective to a bean-counter paradise, it seems to be the common trope: you let business people take complete control of your products' pipeline and the race to the bottom starts, the company can still deliver while the old culture lingers but as more time passes the more problematic these deliveries are until the company has been sucked dry to deliver on-paper good quarterly reports but is rotting from the inside.

Maybe it's a side effect of financial capitalism taking over, maybe it's not but it's quite correlated.

[0] [https://newrepublic.com/article/154944/boeing-737-max- invest...](https://newrepublic.com/article/154944/boeing-737-max- investigation-indonesia-lion-air-ethiopian-airlines-managerial-revolution)

</comment><comment><USER50> The headline is written as if this is the fault of the engineers :/</comment>


Why it's worth learning Go - <AUTHOR> https://medium.com/@rjzaworski/why-its-worth-learning-go-1df48d9dcc48 <comment> village-idiot Go was designed for a very narrow set of constraints that match what goes on in Google. From my perspective it's one of the very few general purpose languages (along with erlang) that were designed to specifically match one company's needs, rather than grown semi-organically.

If your needs align with that somewhat, you might want to use Go. If your needs are different, you should stay the hell away from it.

<comment><USER2> > From my perspective it's one of the very few general purpose languages > (along with erlang)

Maybe I'm missing something, but since when Erlang is a general purpose language? Erlang was designed for a quite narrow niche and feels very well there, but Go... well, honestly, I don't understand what Go was designed for.

<comment><USER3> Go was designed for data munging via gRPC.

<comment> village-idiot One of the clear design needs for go was "you have a crap ton of code you need to write, and you need to _aggressively_ parallelize the work over a bunch of mixed skill devs, without the worst ones fucking it up, and without the best going off the reservation and making something that can't be understood later."

Personally that sounds like my own hell, but that's the world Google lives in.

<comment><USER4> Despite Pike's appalling contempt in [https://talks.golang.org/2012/splash.article](https://talks.golang.org/2012/splash.article) I'm not convinced this is a problem Google actually has. They're faced with perverse incentives but they're far from stupid.

<comment> village-idiot Pike's attitude has been a large factor in me not bothering with Go.

</comment></comment></comment></comment></comment></comment><comment><USER5> Go is a heavy player in the Kubernetes space.

For those in the 'Enterprise computing' business, learning a little Go won't be harmful.

</comment><comment><USER6> There are many reasons to learn Go but even the author didn't emphasise on performance because it is not. There are many dynamic compilers which produce faster binaries than go. I think the best reasoning in the blog was A-Grade standard lib. That is something not all available new languages enjoy. But Go from the early days had good standard lib support. Go comes with batteries but then so does Chicken scheme.

<comment><USER7> From generics to sets and several others, I think there are enough reasons to consider that go does not "come with batteries", especially when you compare it with almost any other modern (>90s) language.</comment></comment>


Ask HN: How have you reduced the pain of moving code between systems? - <AUTHOR> I find the process of moving code between systems (eg from Dev to Staging to Production) to be (unnecessarily) finicky. No matter how much care is taken to harmonize the various environments, very often, subtle bugs creep in. I would like to set up my deployment such that I can be confident that code behaves exactly the same on any of the systems. How do you manage your deployment to ensure consistency across systems? <comment><USER2> Configuration management systems, continuous deployment and orchestration. I have things setup so everything on the server(s) is managed through configuration management. I would recommend having the following environments setup and managed through configuration management (development, testing, staging, production), no need to do manual code pushed and configurations anymore. In staging this is normally where you would have a final review if the amount of code being pushed out is high or it is a new high profile feature that you may want to manually check out before it gets pushed out if you did not want the process to be 100% automated.

I run my code through a continuous deployment system that pushes code that I believe is ready to a testing server where my tests are run. If that goes well, then the code is pushed to a staging server where a similar or duplicate setup of production is orchestrated for each build. Once things look good and pass all the functional, behavioral and other custom automated testing and benchmarking it is automatically pushed out to production. Then production tests are run that are non damaging and check to insure that the new changes are actually implemented, if there are any issues the push can be automatically rolled back along with a report issued on the why it was rolled back along with a listing of any performance or unforeseen security issues that may have occurred.

I will at times have two staging environments if it is a website ( one that uses internal content links and proxies if behind a CDN/proxy service and one that goes through a staging proxy/CDN so I can test for any changes between two. For anything else I like to have an internal and staging setup to insure the probability of a hardware/middleware component causing an issue is decreased.

These multiple environments are little to no issue because they are all automatically setup either from scratch or a pre-built configuration managed image to speed up the orchestration time.</comment>


Looking for a Place to Die - <AUTHOR> http://www.nytimes.com/2011/12/22/opinion/looking-for-a-place-to-die.html <comment><USER2> Sorry to say, I've been through a very similar situation 3 separate times in 3 different cities as the primary caregiver. The least intuitive and most important thing I learned each time was that there are many wonderful options available but you have to find them. Once you do, it's amazing how much easier things get for everybody involved.

There are many levels of care available between intensive care and hospice and plenty of funding available to pay for almost all of them if you look hard enough. Sadly, OP mentions none of this. What an unhelpful article.

There is part-time home health care, full-time home health care, assisted living, nursing homes with multiple levels of appropriate care, and multiple levels of hospice care. (Six days to live or you're not accepted? Shame on them. What kind of thing is that to put caregivers through?)

There is also tons of "care for the caregiver" which is indispensable. I don't how I would have made it without that.

Most importantly, I can't say enough for all of the wonderful people who cared for my loved ones, in many ways much better than I ever could have. They're out there, dedicating their lives to make this inevitable transition better for everyone.

Theresa Brown, I suggest a follow-up "how to" article for caregivers. Unlike this piece, that would take a little research, but could be your contribution to this difficult, but easily addressed problem. You could make it the piece I wish I had read instead of figuring it out myself at the worst moment of my life. Please use the resources of the New York Times to finish the work you've barely started here.

</comment><comment><USER3> If you let an animal die like this, it would be called animal cruelty. I'm happy we have the option here in The Netherlands for a less painful and dignified death.

<comment><USER4> I would also prefer the option of assisted suicide, but hospice is a reasonable option.

Hospice doctors and nurses are trained in palliative medicine, and the hospices themselves are peaceful places, very different then hospitals. I have unfortunately spent significant time at two hospices this year, and had an old friend choose hospice care at home. It was a very humane way to go, with no suffering.

I think self-euthenasia should be allowed, but letting nature take its course has a certain clarity to it. Especially in cases like these, where disease progression impairs decision-making faculties.

</comment></comment><comment><USER4> Put this on your holiday to-do list: discuss with your family when you want to the doctors to give up.

I know that doesn't sound fun, and I know the holidays seem like the wrong time, but there's never a right time. Do it now.

I just went through the cancer-to-hospital-to-hospice transition this fall with my mom, and I am immensely grateful that we had all talked about what we wanted. And then put it in writing, with a living will and a durable power of attorney.

At some point a team of doctors may turn to the person you love best and say "What should we do?" Don't make them guess.

<comment><USER5> ...or this holiday season ask yourself if there's anything more you can help to do to solve this problem. Give money, research, tools, engineering, etc. The War on Cancer started in 1971. 40 years later we should not be reading these types of stories. There are a lot of smart people who read HN. I saw this TED talk last week. There's a lot of inspirational research going on.

[http://www.ted.com/talks/yoav_medan_ultrasound_surgery_heali...](http://www.ted.com/talks/yoav_medan_ultrasound_surgery_healing_without_cuts.html)

<comment><USER4> I entirely support more cancer research, but I wouldn't want people to be disappointed in our progress so far. There will never be a single cure for cancer, because "cancer" isn't a single kind of thing:

<http://www.phdcomics.com/comics.php?f=1162>

Great strides have been made. E.g., one friend with leukemia just takes a daily pill. 40 years ago we would have buried him by now, but since he got cancer he's taken up doing triathlons. Go science!

<comment><USER5> Yes, I understand cancers is plural and there won't be a single cure.. It's not have far we've come, it's how far we have to go. Easy early detection would really help more people. We need to solve a lot of problems, which gets back to my original request. A lot of really smart HN'ers looking for problems to solve.

</comment></comment></comment></comment><comment><USER6> That's so sad, but so real and common. Where I'm from, the law (kind of) allows for euthanasia. People can decide when to die, and have the option of leaving this place in a dignified manner, whit friends and relative in the room.

<comment><USER7> I'm proud that my country does not prohibit assisted suicide. If a person is lucid and has the will to die it's their own decision. It's not like you go to one of these organizations and 2 hours later you're dead.

"Switzerland's laws that prohibit killing continue to apply in full. Direct, active euthanasia (deliberate killing in order to end the suffering of another person) is therefore also forbidden. By contrast, both indirect, active euthanasia (the use of means having side-effects that may shorten life) and passive euthanasia (rejecting or discontinuing life-prolonging measures) – while not governed by any specific statutory provisions – are not treated as criminal offences provided certain conditions are fulfilled."

Source: [http://www.bj.admin.ch/content/bj/en/home/themen/gesellschaf...](http://www.bj.admin.ch/content/bj/en/home/themen/gesellschaft/gesetzgebung/sterbehilfe.html)

<comment><USER4> For what it's worth, I believe that it's the same in the US. Direct euthanasia is definitely illegal. But palliative care that shortens life (e.g., narcotics) is fine, as is passive euthanasia.

The biggest problem I see here is that unless the patient expresses a clear desire to end treatment (either in the moment or via legal documents prepared in advance) then medical professionals must continue to treat. I think the that's a fine way to run things, but it means Americans _must_ be very clear about what they want if they are to avoid dramatic interventions that may do very little to help them and certainly are scarring for the family.

<comment><USER8> Some US states explicitly allow assisted suicide: Washington, Oregon, and Montana.

<comment><USER9> Oregon,for one.

</comment></comment></comment></comment></comment><comment><USER10> I get very angry when I read articles on all the heartless injustice people in the USA have to go through with their terrible medical system. Putting patients in deep debt, going uninsured, people dying because they can't pay for treatments, and now this. I won't give you the primal response I wrote here first and just leave it at "I hope things will improve and become humane again."

<comment><USER11> > Putting patients in deep debt,

The bankruptcies are from living expenses, not medical expenses. Sick people can't work, so housing and so on become a problem. Free unlimited heathcare can't solve that problem.

> going uninsured,

All poor people in the US are eligible for medicaid. Many don't bother to sign up until they get sick. While they're technically uninsured until then, they're not actually uninsured.

> people dying because they can't pay for treatments,

Feel free to list any place that will do every possible treatment "for free". (And no "every approved procedure is free" isn't anywhere near "every possible procedure".)If you can't, we're merely arguing about where "for free" stops.

There's always a point where it comes out of your pocket. Yes, even under the nationalized system.

<comment><USER12> The financial burden is not just for those without insurance or the "poor".

My wife was given a 30% chance in an ICU room earlier this year. Since then we have been through a month in hospital, multiple surgeries, and many doctors appointments. The total cost to date has been over $250,000. Even with insurance we have still paid $10,000 and covered another $10,000 while waiting for reimbursement. The new insurance calendar year starts on January 1st – so we will be paying another $10,000 for a surgery planned in early 2012.

Our household income is $30-40k above the US median and we have savings, but it's amazing how quickly your savings start shrinking when your partner is unable to work and you need to take months of unpaid leave to attend appointments and sit in surgery waiting rooms.

Any politician that talks about fostering innovation and entrepreneurship but continues to support the status quo is a fraud. Surely removing the financial and administrative burden of healthcare for business is better than any tax cut congress could come up with?

<comment><USER11> > Our household income is $30-40k above the US median and we have savings, but > it's amazing how quickly your savings start shrinking when your partner is > unable to work and you need to take months of unpaid leave to attend > appointments and sit in surgery waiting rooms.

Bingo. Heath insurance doesn't address those costs.

> Surely removing the financial and administrative burden of healthcare for > business is better than any tax cut congress could come up with?

And you think that Congress knows how to do this?

Medicare fraud is probably close to $100B/year. How are you going to do better AND reduce costs?

</comment></comment></comment></comment><comment><USER13> Good piece. It's well worth watching Terry Pratchett's "Choosing To Die", about assisted suicide, for an argument of one solution to this dilemma. I'm not sure there's currently a better way to hack death.

<comment><USER14> I've never been a fan of his work, but I have used his driver a few times in London and from conversations with him I suspect I'd like Pratchett as a person a great deal more than his writing. So, thanks for the suggestion, will make sure to watch it some time soon.

</comment></comment><comment><USER15> This was my story, 13 years ago. I did all the care with two kids, 4 and 7. It would have been great to have help.

But the thing that the article misses is the proportion. If the suckiness of death and dying is normalized to -100, then having the hospice care feels somewhere south of 20, moving the experience from a -100 to at best -80.

As much as I dislike our insurance system, I'm not sure it's worth a lot of money for end-of-life help.

<comment><USER4> My understanding is that offering hospice is very cost-effective. For a lot of people the only reasonable alternative is staying in a hospital, which is very expensive.

</comment></comment><comment><USER16> No one should be put in a dilemma like that, human life&death is not something that can be processed by insurance companies as logical/profitable. Our govts must be able to provide free health care at least for the dying. And no family should be seperated like that they cannot get together when one of them is dying and needs all the attention.

</comment><comment><USER17> nobody ever wants to die, but given the choice, I think most would prefer their home over a hospital, I know my dad did

</comment><comment><USER9> Well that was a cheery, uplifting article. I'm not quite sure it's in keeping with the Festivus spirit.

<comment><USER18> Cope.

</comment></comment><comment><USER19> Wow.. moving piece.</comment>


Earth Temperature Timeline - <AUTHOR> https://xkcd.com/1732/ <comment><USER2> The maximum temperature on this chart before 2000 is 5000bc.</comment>


The Development of Chez Scheme (2006) [pdf] - <AUTHOR> http://www.cs.indiana.edu/~dyb/pubs/hocs.pdf <comment><USER2> I was happy to read this... it seems to me that adding a compiler optimization that in turns makes the compiler significantly faster must be some kind of thrill in itself.

<comment><USER3> I am told that Niklaus Wirth only allowed for compiler optimizations in which the optimizations paid for themselves in speed, when compiling the compiler. This is said to be the reason for the Oberon compiler's speed. [1]

I have only skimmed Dybvig's paper on Chez Scheme, but I think it would be interesting to compare the speed of a compiler that uses Dybvig's nanopass framework [2], and a compiler optimized according to Wirth (using only a single pass).

[1] [https://books.google.com/books?id=6kHs4s-79bkC&lpg=PA44&ots=...](https://books.google.com/books?id=6kHs4s-79bkC&lpg=PA44&ots=B3uRPNfAJB&dq=wirth%20compiler%20faster&pg=PA43#v=onepage&q=wirth%20compiler%20faster&f=false) [2] [http://www.cs.indiana.edu/~dyb/pubs/nano- jfp.pdf](http://www.cs.indiana.edu/~dyb/pubs/nano-jfp.pdf)

</comment></comment><comment><USER4> It was a fascinating read of evolving a system from 8-bit to 32-bit to 64-bit with many rational or clever development choices. I like how they kept improving performance while keeping quality as high as can be. The willingness to rewrite or toss what was necessary to keep the whole thing sensible is quite a contrast to other legacy systems that force people to work around crud forever. They also learn from the past better than most in that a solution to an 8-bit problem in version 1 ended up solving a similar problem in the last, 64-bit version. Shows value of keeping those old tricks and papers stashed somewhere just in case.

Definitely adding it to my collection as there might be lessons for a Racket reimplementation or a certified LISP project in the future. Hell, their low- level stuff might even be useful in a LISP processor or hardware/software architecture. Who knows. Thanks for the good read, though.</comment>