Facebook Engineering Process


Facebook. My understanding. is that around that time. Facebook really didn't have much testing and it's kind of ironic because you were the creator of extreme programming. It was highly dependent on the process of writing unit tests and then writing the features facebook clearly reversed that process and was able to be successful despite the fact that they wrote their features before they their their tests. You you often hear that you need. Unit tests in order to build things like continuous integration. Continues to degration. Lets you move much faster because you have this battery of unit tests that runs at every new build. But i don't think facebook had that stuff until later. How is facebook able to move so fast with such a low amount of unit testing. Yes so that was. That was part of the puzzle. One when i arrived one of those. Hey this isn't what's in the books and yet it seems to be working and the answer that came to is that while the there's a couple parts of it one is. How many of your problems can you test for. And how many problems. Only show up in production so if if problems like if you're writing a simple calculation but it might not scale in production you you can't write unit tests for it so the facebook cancer is don't that's part of it is depending on the ratio of. How many problems is it possible to test for before. Production versus after if that ratio is skewed towards. Hey stuff only fails in production then. Don't write any tests. The second part of the answer is tests are a form of feedback and facebook. Engineers had many many other forms of feedback. So you'd right on your development server and you'd try stuff out and then it would go through code review his second form of feedback and then it would at that point it would roll to the internal site. So you get more feedback from that and then it would go through the deployment process where it would get rolled out to a small number of machines and then and more and you get feedback from that and then A logging and like operational awareness was just part of the engineering culture. So you'd get feedback post production of like how your feature actually was was behaving so. There's a bunch of feedback loops in place. Unit tests occupied for most development facebook. Just the cost benefit the amount of feedback. They added the timeless timeliness of that feedback and the cost of achieving that feedback. Just wasn't worth it the so in bootcamp. You're supposed to put code in production. The first week. And i was very careful to write tests than do everything properly. So i got in a fair amount of of. He got a fair amount of heat. Because my first feature didn't land for three weeks and people are like well. I don't know how this is gonna work out. One i was. I was wondering that too. I had a huge case of imposter syndrome. When i when i landed at facebook and realize just how different everything was and then the tests that i had written broke almost immediately and they were deleted. That was one of the things that surprised if if you had if you had a test and it failed but the site was up. They'd just delete the test. If you had tests that were intermittent that that were non deterministic. There were just deleted. And at first i was shocked. Like deleted attest. This is producing noise. And it's not producing signal if you eliminate this this noise production per definition. The situation is clearer all of a sudden the fact that you kinda wish that you had to test for something while you didn't and so yet just chuck it. Let's move on now. You probably wouldn't want to take that approach to nuclear power plant software or electricity grid software. That seems like a practice. That is uniquely useful. Four kind of early facebook where this thing wasn't yet a communications utility. It was more of a fun thing to do akin to

Coming up next