Funny, mostly because these three exhibits (and I'm pretty sure there's plenty others) are a blatant proof of the issue with hiring young programmers (read "no one over 30")...
The evidence here is three times "If brute force doesn't solve your problems, then you aren't using enough." which is the route chosen by uncultivated people in any domain. (myself included)
Among which I often hear:
- "Just add more RAM, it doesn't cost much nowadays!"
- "Just push it to <insert well-known hosting plaform, preferably A.z.n> using <insert overhyped virtualisation platform>"
- "Just use to NoSQL, it's faster!"
(sigh)
Whenever my previous team leader would suggest "just" doing something I took it as a sign that he hadn't actually thought things through very thoroughly.
>Culture matters. The “Hack” and “Move fast and break things” culture must make it very hard for developers to focus on quality.
Every now and then production questions the business value for this. Recently my company released a new game feature and we had to throttle it back in a hacky way immediately as user did not like it. However the database calls and code are still being executed. Now the business does not want us to revert the code (or re-implement the throttle in proper way ) as they see no business value in that and fear of breaking other things as part of this "unnecessary" code changes.
I tried to explain that we just stopped the feature as it was an emergency as we did not have time to revert and re-push the server. This feature was well tested (not a brand new feature ) so we did not have a throttle . We found a hack and manage to stop the feature so that users are not outraged.
May be the right decision was not to tell about the hack to the business at all. They would have have to wait till we revert the code properly and re-push the server. But as an engineer you worry about the product as well, we I could not resist .
I must say I haven't smiled so much as with Exhibit C: Our site works when the engineers go on holiday
In their defense I wouldn't be surprised if many companies had similar graphs especially as there was no Y axis and there is no cost associated with incidence, but still worth a chuckle.
As for just tossing more engineers at a problem it is going to be painful when they decide to stop adding engineers to work on the iOS app. Suddenly you don't have new devs with nothing on their plate ready to make new software, but all you have is engineers that are spending most (if not all) of their time maintaining what they have so there will be not many devs free to build stuff and those that are will take a while to get it done given the little free time they have to devote to the effort.
This has played out many times before at many other companies. Soon a little group will be formed to reduce the technical debt and improve the architecture. They will do their best, but have a hard time unless there is a fundamental shift in culture (think Microsoft with security in 2003).
Pretty much everyone I know who is a programmer ( including myself ) has been receiving spammy non-solicited recruitment emails from Facebook ever since their IPO. I've been predicating this decline in code quality for years.
Facebook is also rather aggressive with their recruitment. I've specifically asked them on multiple occasions to NOT contact me with job offers. Facebook straight up ignores these requests. I've now been contacted by at least three separate Facebook recruiters. Mind you, I've NEVER applied to work for Facebook and I don't even have a Facebook profile.
I'm sure a lot of people already suspected this, in 2013 a Facebook engineer proudly stated that they've hacked their way around a dalvik vm limitation[0] for their app to work on Android 2.2-2.3.
It's the attitude that "hacking things to work is okay" is causing extremely bad reliability issues even when using a top of the range android phone or latest iOS device.
Have they ever thought that maybe 18,000 classes is a bit too much?
Nearly 300B market cap - actually way more than I would expect. This elitist attitude needs to stop. The user doesn't give a shit about your technology. If your preferred technology mattered at all, you be able to compete easily at 1/1000th the scale at a minimum. Yet you cannot even do that.
this is a often used arguments but it seems to answer the wrong question :
facebook didn't become popular because it had technical abilities or qualities that no other companies had. i mt became popular because of good product features and good marketing ( in the most general sense). So, to them, using a bad technology wasn't such a big deal.
it doesn't mean php is good, it just means that some businesses can afford a bad technological stack. Even online ones.
now, as software developpers, we should try to use the best technology whenever we can ( with best being relative to the business constraints of course).
But commercial success and technological achievments are two different things. sometimes they're linked (think whatsapp), sometimes not.
I agree and you are saying the same thing I did. I just pointed out that dogging on a company's technology choice, because you don't like it, despite the company having ~300B market cap, is silly, especially since the article talks about iOS, the # of engineers, and their company culture of moving fast & breaking things. That has nothing to do with PHP itself.
It is extremely rare that an internet company fails because of their technology choices. At the end of the day - the user does not care about your technology. They only care about the user experience and the value your product delivers.
The evidence here is three times "If brute force doesn't solve your problems, then you aren't using enough." which is the route chosen by uncultivated people in any domain. (myself included)
Among which I often hear: - "Just add more RAM, it doesn't cost much nowadays!" - "Just push it to <insert well-known hosting plaform, preferably A.z.n> using <insert overhyped virtualisation platform>" - "Just use to NoSQL, it's faster!" (sigh)