Comment by nwsm | Hacker News Reader

Comment by nwsm | Hacker News Reader

Great thread.

> So said brilliant engineer in Amsterdam, built an annealing algorithm in the release build to reorder the optimization passes in such a way to as minimize size. This shaved a whooping 11 mbs off the total machine code size and bought us enough runway to keep development going.

> This terrified the Swift compiler engineers, they were worried that untested complier pass orders would expose untested bugs

This would scare me too.

> I had privately had the “we need to stop” conversation with my director. He told me that if this project fails he might as well pack his bags. The same was true for his boss all the way up to the VP. There was no way out.

This brings up an interesting point. The author attributes some decisions in the thread to the "sunk cost fallacy". The business costs were sunk, but if the employees and management are too afraid for their job to make the "cut your losses" decision, the costs are not really sunk, at least not in the minds of the right people.

This isn't sunk cost; the exec chain just has different incentives. They're hired for outcomes. It's their job to make it happen, not make it make sense.

> A bunch of people got promoted. We all breathed a sigh of relief. The 90 work weeks stopped for a few weeks.

When you move up, you move on; issues from then on are the next guy's problem. Exec dynamics are often "gather successes to me and push off failures to others" - sounds like some exec won.

> > This terrified the Swift compiler engineers, they were worried that untested complier pass orders would expose untested bugs

> This would scare me too.

For what it's worth a few (10ish) years ago we did this with the J9 compiler at IBM (technically just the backed that was shared between Java, C++, etc). Same idea with simulated annealing. It did end up finding some really strange bugs, but they were bugs that were present regardless, we just hadn't found the right test case for it. We did end up getting some performance out of it, but not nearly as much as you'd expect. It mostly boiled down to running a few extra constant folding passes.

It sounds almost like it is a kind of fuzz-testing then; I'm interested in what percentage of problems uncovered were problems in the spec or undefined behavior, versus problems introduced by the simulated annealing itself.

Almost every large engineering team has someone with the skills to do terrible, but powerful things like these. You should be scared, not of those people or their work, but the situations in which these people become necessary. Strive to make it so that they are not needed. Too many engineering teams, especially at certain large companies (of which Uber is one), fail to understand this.

Uber also has a habit of solving problems by hiring a manager externally and building a brand new team of all new hires for them.

There's some upsides to that, but basically even though you're a W-2 employee, you're effectively a consultant in that arrangement. Your job is not secure.

> annealing algorithm in the release build to reorder

This is a damn cool use of simulated annealing.

>> This terrified the Swift compiler engineers, they were worried that untested complier pass orders would expose untested bugs

> This would scare me too.

FWIW, I made it clear that this was also a great way to break the app :)

Reply on news.ycombinator.com