I do game for a living. I guess I assumed that people knew that games were optimized, though they usually don't fall under "enterprise." Oculus falls under gam

I do game for a living. I guess I assumed that people knew that games were optimized, though they usually don't fall under "enterprise." Oculus falls under games for me, which is unusual to find in an enterprise company, and frankly probably isn't being run much like the rest of Facebook anyway, so the point is rather moot. >That could mean enumerating all the possible applications of high performance software, or it could mean enumerating all of the strategic goals of a piece of business software and identifying that performance isn't one of them. I'm a big fan of optimization, and yet I've done exactly the latter and come to the conclusion that a particular admin backend that would never have more than, say, a couple dozen users EVER would be fine to be written in Ruby. It was an internal tool, and the available engineers were efficient in Rails, so I gave a green light for them to write the admin tools in Rails. There wasn't even a debate. I just said yes, go. But when you're writing a service that should have a solid front-end that can scale, you need to design scalability into the architecture. It seems to rarely happen. >With respect to the backend of their main application, they created things like Cassandra to meet their unique database needs. Cassandra is good and well optimized. Point. >In the former case, you're going to feel like you've enumerated enough (e.g., three examples) and then come short of the actual space of high-performance problems. Those are the things that came to mind. No, I'm sure I didn't hit all possible high-performance issues. But that's probably the 80th percentile. And at least 95% of "enterprise" problems are not treated with the respect they should be toward optimizing. That I have from several personal sources. >They put in a lot of engineering effort to make the best client for the appropriate device. They put in 100x as much engineering effort as they should have needed to to create a solid mobile app, and the result is a monstrosity of garbage. Several indie developers have produced replacement Facebook apps that are far better, faster, and would actually be more robust if Facebook weren't actively trying to prevent them from working. So you can't tell me you need a hundred developers writing generated code to create two apps (the main Facebook app and Facebook Messenger; if you want to read messages, the main app has that DISABLED with a nag screen to download Messenger if you want to read messages) are actually even remotely competent (as a group) if some developer in their bedroom can crank out a better app in their spare time. I've also written an entire app from the ground up that had about 80% of the Facebook app's functionality, written against some of the worst backend APIs you can imagine (a mix of non-standardized, inconsistent XMLRPC, JSON, and other APIs) and it took me, writing code entirely by myself, about 5 weeks. To a finished, polished product. And that's at only about 30 hours a week. >In the latter case, in my personal experience developing a line of business application, it turns out that performance eventually starts to matter. It sort of becomes the hardest problem, like people have said elsewhere. I don't dispute that they should pay attention to performance. I just dispute that enterprise developers (excluding exceptional situations like Cassandra) actually optimize architecturally. Sometimes they can't for structural reasons, since ideal optimization needs to happen across teams and domains, which can be difficult in an environment where each team controls a domain.