Developers of an app used by over a billion people do not know how to develop software because you wrote a small CAD app one time? Right.
I think someone should reach out to them and let them know that they just have to gzip their XML!
I think someone should reach out to them and let them know that they just have to gzip their XML!
BTW I’ve wrote much more than 1 app in my life, I’ve been programming for living for 18 years already. Mostly desktop software, some mobile, videogames, and embedded. I haven’t developed web apps but I’ve interacted with many people who did, I think they have slightly different mindset, the areas are just too different.
What I think might have happened, FB hired people based on the criteria dictated by their main product, facebook.com web site, then told them to write that iOS app.
And you should definitely not postulate on their ability to develop software based on that utter lack of knowledge.
I know what they did. They’ve made an 0.5GB mobile app that downloads some data from a server, and displays it with a nice 2D rich GUI. I’ve wrote a few similar apps, both for iOS and WP.
> the constraints they had
Again, I know most of the constraints they had. Unlike PCs or especially lower-level platforms like game consoles or embedded Linux, at least 50% of these constraints are dictated by Apple and should be known by every developer with the access to iOS SDKs. Other constraints are dictated by internationalization, Asian languages and RTL layouts indeed complicate a few things, but not enough to justify the size. Same for multi-platform development, data caching, and security & privacy constraints.
The only thing I don’t know about these constraints is their client-server protocol (not because I don’t work in FB, it’s possible to reverse-engineer with a sniffer, I just never cared). But if it’s network-related code that’s so complex, I would consider making a server-side proxy, to expose mobile-friendly protocol. BTW I did that too, when I was working on mobile bank clients.
> or the kind of people they hired while developing it
I agree with you on that. I don’t know anything about FB, I‘ve just guessed about it.
That's the problem. You and I both have no clue. Do you really, in your heart and hearts, believe that writing an app for the number of markets Facebook has, with all their weird quirks and all the features they support would have 50% of the constraints imposed by Apple?
Look, I do get your point and there are nuggets of truth to them, but overall your argument is like someone saying: "pfft, Google runs millions of servers? I've written assembly, they could run their whole infrastructure on 10 servers if they just knew how to write proper software".
I hope you can see how patently ridiculous that is.
Yes I do. The client functionality is relatively simple, even with all these per-market quirks and features combined.
And Apple did excellent job providing stable hardware & software environment, and deprecating old hardware. Per-user quirks are almost non-existent on iOS. This is unlike PC platform, for that CAD app I had to spent significant time implementing various workarounds for users on old PCs, Intel breaking GPU drivers, and many other strange things.
> I hope you can see how patently ridiculous that is.
Scaling web apps is relatively hard. A system running on 1M servers is way more complex than similar system running on 5 servers.
An FB user however only has a single iPhone in their pocket, with 4-6 cores and 2-3GB RAM. The mobile software doesn’t and shouldn’t care how many servers FB has in their datacenters, or how many petabytes of data are stored on these servers.
However, facebook didn't wrote the ios app overnight. They got to this point because of a long trajectory of lots of tradeoffs, some heavily related to the human, organisation, social side of software development - its hard to coordinate an effort across probably dozens of teams.
You're commenting on a 10ton freight train travelling at 50km/h saying you can build a faster car. Well, they probably started with a car, too but built a train along the way. I'm sure if they rewrote it it would be much better but that's just how things are in software. Doesn't mean we shouldn't look at the app size, but don't forget the trajectory instead of looking at the last data point.
I agree with you on that, but hard ≠ impossible.
I was fortunate to work in a couple of large companies with good technical management. The companies did OK even for large software with 10+ years of legacy C++ code. It indeed required significant effort to coordinate teams and people. But if you’re a technical lead in a software company, it’s exactly your job to accomplish that.
If user wants to travel by a car and a company’s telling them “you can ride our awesome freight train instead”, it might mean the company has failed to manage the software development part of their business. It’s even possible the developers were top-notch professionals, but technical management wasn’t, and the management prevented developers from doing their job well.
Absolutely nothing.
I think the more accurate way would be that scale has absolutely everything to do with it, from the way you develop your systems at the very lowest layer (architecture, code layout, optimisations) to the very highest (the UI).
Designing software for 1,000,000,000 users is an entirely different ballpark than for 1,000. Different trade offs, different restrictions, different everything.
There is a reason Google had to invent their own freaking database (using atomic clocks to handle transactions no less) to get to their scale, and it's not because they were a bit bored and fancied giving it a go.
This is in part what I meant by different mindset.
For web developers, dealing with the complexity caused by massive scale is inevitable, and yes, for them it’s different everything.
Desktop and mobile developers are essentially shielded from that complexity by slow networks. It’s technically possible to VPN into DC and write mobile apps as they were a server app, but even ignoring security considerations, this is usually wrong approach. Within DC you have 0.5ms latency, over mobile Internet it’s 200ms best case. These 2-3 orders of magnitude make great difference on how you should design software.