3 ms·

I started to write a whole big thing here because I found this whole thing pretty disgusting but it's not worth it. > I had privately had the “we need to stop”

I started to write a whole big thing here because I found this whole thing pretty disgusting but it's not worth it. > 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. > With only a week left we decided eat the 8 figures and drop support for iOS 8. I'll say this: If I were an Uber investor I would be pretty angry. And the story just gets worse from there. This is a story of gross incompetence. It's not an engineering disaster, it's a management disaster. This is classic "inmates running the asylum". ( https://www.goodreads.com/book/show/44098.The_Inmates_Are_Running_the_Asylum https://www.goodreads.com/book/show/44098.The_Inmates_Are_Ru... ) This is the story of some hackers who got in good at a big company with lots of money and sturm und drang so they had no adult supervision while they partied while pretending to be actual engineers. (That they were pretending to themselves too doesn't make it any better.) The writing was on the wall, but rather than own up and take responsibility they double down and keep messing things up for months and years. > This is when the real brilliant engineers started to shine. This is when they get pulled from other tasks to clean up your mess! (cf. Broken window fallacy.) Those real brilliant engineers should be doing other better things than dark rituals to appease the Swift compiler gods. Look, we all make mistakes. There's a blog post from an engineer at a company I used to work for complaining about the pointless middleware I wrote years earlier. (I feel ya bro, I told them at the time that it was pointless.) Here's the thing: I got out of that place when I realized that the folks running it weren't really competent. (And, sure enough, they got pushed out by the investors and now the company is a "Wallstreet darling". So... Yay?) I've burned enough investor money in my career that I don't think it's funny anymore. (I never really did think it was funny, I don't like waste, but I was young. REDACTED was only my second official job, and in hindsight it was really crazy. I mean, they built a skating half-pipe in the office! At the time, everybody thought that was real cool.)

Apocryphon 6y ago
One wonders if this is common everywhere at this scale. Take Facebook's massively bloated iOS app: https://www.reddit.com/r/iOSProgramming/comments/6upeu6/how_on_earth_is_the_facebook_app_size_so_large/dluf4rc/ https://www.reddit.com/r/iOSProgramming/comments/6upeu6/how_... https://news.ycombinator.com/item?id=14903228 https://news.ycombinator.com/item?id=14903228 And their Android app patching Dalvik at runtime to deal with the huge number of Java methods: https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920 https://www.facebook.com/notes/facebook-engineering/under-th... And they're not the only ones known for bloated apps, either. Take Amazon's apps for instance: https://news.ycombinator.com/item?id=14902875 https://news.ycombinator.com/item?id=14902875
- pandanomic 6y ago
  Misinformed take. Android natively supports what facebook did back then, because almost every app hits the dex limit.
  - Apocryphon 6y ago
    Not an Android dev, just going off of how the FB comments there and elsewhere have responded to that article.
- Groxx 6y ago
  I suspect it is common. And mostly inevitable. When you have 10^N engineers working on something, protecting them from each other (and themselves) grows increasingly important. At some point, it becomes your main priority, as without it you have a totally non-functioning system. Which partly implies that the only solution is to not grow to that scale. Keep a smaller, more skilled team instead. In most cases I think that'd be better, and I think most people (and companies) would agree (if only they could hire those skilled teams reliably)... ... but sometimes throwing more people at a problem really is the best (or only) option, e.g. when you have to deal with a large volume of ridiculous external constraints. For example: my first job was at a company that aggregated loan providers, which entailed consuming hundreds of random PDFs per day and dozens of weird RPC calls. We had dozens if not hundreds of hand-crafted bits of automation to detect when things changed and handle the new format. Many APIs had hand-rolled XML parsers and producers... because the company we were calling would choke if your attributes weren't in a specific order, or if X wasn't within a specific number of bytes from the start of the request, or they returned invalid XML. It was absolutely ridiculous, but there's no way a bunch of banks were going to fix their APIs for us, so there's not much of an option but to do it by hand.

Apocryphon 6y ago

One wonders if this is common everywhere at this scale. Take Facebook's massively bloated iOS app: https://www.reddit.com/r/iOSProgramming/comments/6upeu6/how_on_earth_is_the_facebook_app_size_so_large/dluf4rc/ https://www.reddit.com/r/iOSProgramming/comments/6upeu6/how_... https://news.ycombinator.com/item?id=14903228 https://news.ycombinator.com/item?id=14903228 And their Android app patching Dalvik at runtime to deal with the huge number of Java methods: https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920 https://www.facebook.com/notes/facebook-engineering/under-th... And they're not the only ones known for bloated apps, either. Take Amazon's apps for instance: https://news.ycombinator.com/item?id=14902875 https://news.ycombinator.com/item?id=14902875

pandanomic 6y ago
Misinformed take. Android natively supports what facebook did back then, because almost every app hits the dex limit.
- Apocryphon 6y ago
  Not an Android dev, just going off of how the FB comments there and elsewhere have responded to that article.
Groxx 6y ago
I suspect it is common. And mostly inevitable. When you have 10^N engineers working on something, protecting them from each other (and themselves) grows increasingly important. At some point, it becomes your main priority, as without it you have a totally non-functioning system. Which partly implies that the only solution is to not grow to that scale. Keep a smaller, more skilled team instead. In most cases I think that'd be better, and I think most people (and companies) would agree (if only they could hire those skilled teams reliably)... ... but sometimes throwing more people at a problem really is the best (or only) option, e.g. when you have to deal with a large volume of ridiculous external constraints. For example: my first job was at a company that aggregated loan providers, which entailed consuming hundreds of random PDFs per day and dozens of weird RPC calls. We had dozens if not hundreds of hand-crafted bits of automation to detect when things changed and handle the new format. Many APIs had hand-rolled XML parsers and producers... because the company we were calling would choke if your attributes weren't in a specific order, or if X wasn't within a specific number of bytes from the start of the request, or they returned invalid XML. It was absolutely ridiculous, but there's no way a bunch of banks were going to fix their APIs for us, so there's not much of an option but to do it by hand.