Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Facebook Ships Code

framethink.wordpress.com

Post reply on HN
Print view View original

101–110 of 116 posts

Re: How Facebook Ships Code

#101

Post by tedunangst »

mgkimsal wrote: post #100
tedunangst wrote: post #89

Earlier quoted context omitted.

Adding on top of that was my own dynamic language background not mapping well to the JVM - one bad address in the middle of a loop doesn't just get skipped and logged, but the entire process now stops. Makes me wonder what dynamic language you're used to. An uncaught exception in both python and ruby aborts the program, not just the tiny inner loop that happens to be running.

Primarily PHP, although I seem to remember classic ASP VBScript not dying if you passed a bad email to CDO (but that's been a long time, so i might not remember that correctly). PHP would not throw an exception if the mail function got a bad email address. well, using some mailing libraries might , but the core mailing function (basically just a wrapper for sendmail/postfix CLI stuff) wouldn't.

Oh, you expected silent failure from a crappy library. :) I think Java (or rather, the library you're now using) made a much better decision to not blunder along.

Re: How Facebook Ships Code

#102

Post by Silhouette »

lmm wrote: post #95
Silhouette wrote: post #10

Am I the only person who thinks this whole approach is broken? We have seen the rise of "devops" recently, and big name web companies like Facebook and Google seem to be very proud of how engineer-led they are, how empowered their developers are, how their product managers don't have much real authority, how they push code to production ten minutes before it's even written, and so on. From the outside, I see systems…

>And I see huge brands whose egotistical staff don't realise that they are successful despite evidently not bothering with either real product management or robust testing, not because of these things Citation needed. The massive public success of these companies would argue against you, as would my personal experience working with and without traditional project management.

The massive public success of these companies would argue against you

What massive public success would that be?

Let's ignore the underlying platforms that originally made them: search, ads, and arguably GMail for Google; and reaching critical mass on the social graph and ads for Facebook. Those were developed long before the developer culture we're discussing here. Since then, what massive successes has all this developer-led initiative produced?

Google has made or bought a string of flops, most of which have been shut down one after another. It's doing OK with Chrome and Android, but neither of those is exactly a shining example of high quality software development.

Facebook has... Well, what? Repeated changes to the UI that seem to irritate more people every time(line), repeated privacy lapses, and repeated backtracks in the face of widespread criticism from their user base?

Neither business seems to have any sense of direction. Google seems to be trying to consolidate under Page by aggressively cutting out anything that's not a big ticket item in the portfolio, which might well be a good move, but it remains to be seen how well they can innovate using anything other than the what-sticks-to-the-wall strategy that they've adopted in recent years. Facebook just seems to be trying to find more ways to exploit information their users have explicitly decided to make private and get away with it.

Re: How Facebook Ships Code

#103

Post by lmm »

Silhouette wrote: post #102
lmm wrote: post #95

Earlier quoted context omitted.

>And I see huge brands whose egotistical staff don't realise that they are successful despite evidently not bothering with either real product management or robust testing, not because of these things Citation needed. The massive public success of these companies would argue against you, as would my personal experience working with and without traditional project management.

The massive public success of these companies would argue against you What massive public success would that be? Let's ignore the underlying platforms that originally made them: search, ads, and arguably GMail for Google; and reaching critical mass on the social graph and ads for Facebook. Those were developed long before the developer culture we're discussing here. Since then, what massive successes has all this dev…

>Let's ignore the underlying platforms that originally made them: search, ads, and arguably GMail for Google; and reaching critical mass on the social graph and ads for Facebook. Those were developed long before the developer culture we're discussing here.

Huh? Do you think they started out as straight-laced businesses with traditional project managers, and then arbitrarily decided to get rid of them after they became successful? Their cultures were always like this; did you see the recent story here on how Facebook was in its 30-person days?

Re: How Facebook Ships Code

#104

Post by damncabbage »

mgkimsal wrote: post #100
tedunangst wrote: post #89

Earlier quoted context omitted.

Adding on top of that was my own dynamic language background not mapping well to the JVM - one bad address in the middle of a loop doesn't just get skipped and logged, but the entire process now stops. Makes me wonder what dynamic language you're used to. An uncaught exception in both python and ruby aborts the program, not just the tiny inner loop that happens to be running.

Primarily PHP, although I seem to remember classic ASP VBScript not dying if you passed a bad email to CDO (but that's been a long time, so i might not remember that correctly). PHP would not throw an exception if the mail function got a bad email address. well, using some mailing libraries might , but the core mailing function (basically just a wrapper for sendmail/postfix CLI stuff) wouldn't.

"on error resume next" redux?

Re: How Facebook Ships Code

#105

Post by alttab »

Daniel_Newby wrote: post #98
alttab wrote: post #54

Earlier quoted context omitted.

True - but those engineers don't work at Facebook. This isn't no-child left behind. This isn't hand-hold time. This is the most expensive and expansive internet application in the world. If they need time to ramp up, they can do it on someone else's product and come to Facebook when they're ready.

"This is the most expensive and expansive internet application in the world." Facebook uses chat/pictures to sell ads and cheesy games. Their entire value proposition comes from surfing a wave of attention. What they need are scruffy surfer dudes who keep an eye on the weather, show up at the likeliest beaches, and never stop riding the waves. Anyone with a modicum of skill who keeps paddling out to try again can mak…

I never said what they did was important. I said it is the widest used, most distributed, and most encompassing software on the planet.

What it provides is trivial, how it does it is not.

Re: How Facebook Ships Code

#106

Post by Silhouette »

lmm wrote: post #103
Silhouette wrote: post #102

Earlier quoted context omitted.

The massive public success of these companies would argue against you What massive public success would that be? Let's ignore the underlying platforms that originally made them: search, ads, and arguably GMail for Google; and reaching critical mass on the social graph and ads for Facebook. Those were developed long before the developer culture we're discussing here. Since then, what massive successes has all this dev…

>Let's ignore the underlying platforms that originally made them: search, ads, and arguably GMail for Google; and reaching critical mass on the social graph and ads for Facebook. Those were developed long before the developer culture we're discussing here. Huh? Do you think they started out as straight-laced businesses with traditional project managers, and then arbitrarily decided to get rid of them after they becam…

Do you think they started out as straight-laced businesses with traditional project managers, and then arbitrarily decided to get rid of them after they became successful?

No, I think they each started out with one good idea that they executed well enough and I think each also had the good fortune to be in the right place at the right time. They made great successes out of their respective founders' big ideas and their first funding rounds, but that was nearly a decade ago in Facebook's case and well over that for Google.

Today, these organisations have been considered among the most desirable employers for many of the best and brightest software developers of a generation. They have more money than they know what to do with because of those original successes, and they have thousands of very smart people working for them. No-one can credibly claim that they don't have vast and talented software development teams.

And yet, neither has produced an industry-shaking development in several years, never mind creating any new markets, and their original successes continue to bring in by far the lion's share of their revenues. I don't see how you can blame that on anything other than a lack of leadership and vision from the other parts of the organisation. The people who are supposed to be guiding and nurturing and co-ordinating just don't seem to be there, and it seems they're still trying to operate like that 30-person organisation, just scaled up by an order of magnitude or three.

Re: How Facebook Ships Code

#107

Post by SatvikBeri »

accountoftheday wrote: post #93
SatvikBeri wrote: post #92

Earlier quoted context omitted.

Exactly. Companies are legally required to go public if they have >500 shareholders, which Facebook has had for a while due to investors + stock options.

Wrong. You can stay private with >500 shareholders, you just have reporting requirements matching those of a public company.

You are correct. I should have been more precise: once a company has >500 shareholders, they the same reporting requirements as a public company. Since reporting is one of the biggest disadvantages to going public, this means that companies with >500 shareholders are very strongly incentivized to go public.

Re: How Facebook Ships Code

#108

Post by mkjones »

darkarmani wrote: post #85
gaius wrote: post #55

Earlier quoted context omitted.

Right. FB doesn't get that all they have is the user experience, and it is bad user experience if I drop out of a conversation I'm having because their DBA-free database has decided to simply, silently drop my last comment. Or if it takes me several attempts to post a photo. Or if I invite someone to an event, and they never get the invite. You can do all sorts of amazing things if you just don't care if your code ac…

> Grown-up companies have full-time professional DBAs I don't know if I'd call them "professional," but they definitely have full-time DBAs. ;)

What do you mean? I've worked with some of our DBAs, and they're quite good. In fact, I can't think of a single site issue that was caused by a DBA. I work on fighting spam at FB, and we make use of mysql quite a bit.

Re: How Facebook Ships Code

#109

Post by mkjones »

jacques_chester wrote: post #12
michaelmartin wrote: post #3

I really like seeing this approach listed: "resourcing for projects is purely voluntary. A PM lobbies group of engineers, tries to get them excited about their ideas. Engineers decide which ones sound interesting to work on." That sounds exactly the same as how Github's engineers work. It's an awesome concept; no-one can justifiably be bored with their projects if they chose them. And if you can't get anyone interest…

> It's an awesome concept; no-one can justifiably be bored with their projects if they chose them. Eventually people lose interest. It's only human. But The System has been written, it is in production, and it has accrued a healthy stock of user data. One day, The System breaks. "Only" tens of millions of users -- less than a percent of all Facebook users -- rely on the The System. But they rely on it utterly. Who wi…

I actually haven't seen this much as an issue at Facebook (I've been an engineer there for a few years). There are some (usually very smart) people who care a lot about systems working reliably, and almost always seem to be a few who are willing to jump on issues like this.

One of the advantages of the "bootcamp" approach outlined in the OP is that people feel empowered to jump from product to product, so if something you care about breaks for a small set of users and you wish to fix it, you can do that. As a few others have pointed out, it doesn't hurt to mention this at review time, and people are often publicly recognized and thanked for these "thankless" efforts.

Re: How Facebook Ships Code

#110

Post by mkjones »

krosaen wrote: post #97

""" Engineers responsible for testing, bug fixes, and post-launch maintenance of their own work. there are some unit-testing and integration-testing frameworks available, but only sporadically used. """ Sounds like a lot of code debt accumulating that could bite them hard down the road - it's one thing to write and manually verify bug free code, it's another for a different engineer to make sure he/she doesn't break…

This article's about a year and a half old. We have pretty good unit test coverage on a good chunk of our code (especially core stuff), though admittedly not everything.

Some groups put particular emphasis on this (e.g. the messages team is great about testing), and it shows in the reliability of their products. Even better, they end up building frameworks that make it easier for the rest of engineering to write tests, and drive the whole ecosystem forward.

Post reply on HN