1/ Yesterday @software_daily published a podcast with @floydophone and I as part of the series on FB eng. What started as a "bear case" ended up being more of a holistic assessment. It's a distillation of things we've learned from the whole series.
softwareengineeringdaily.com/2019/10/30/fac…
softwareengineeringdaily.com/2019/10/30/fac…
2/ I'm really proud of this interview and touches on a lot of themes/issues I care about. In previous episodes, I've tried to do huge one day tweetstorms about these podcasts but that's really chaotic. So I'm going to break it up over a few days.
3/ Today's installment will be regarding @the_prion's opening question: "What are the downsides of moving as fast as Facebook did?"
4/ @floydophone weighed in and talked about that it can be really difficult to new engineers, especially ones who have never worked in an environment like that.
5/ For example when he joined he found that documentation was out of date and had to resort to finding commit histories or discussions buried in PRs/diffs. There often weren't coherent design docs where you could get up to speed on something complex quickly.
6/ Lots of engineers are simply not used to dealing with that and can't adjust, and it can cause engineers to churn out who otherwise could be very effective. Even for those who adjust, it can cause confusion and unnecessary chaos.
7/ I took a different tack. So the obvious thing that people say is that "Oh you sacrifice quality in order to get speed". I actually think this a false tradeoff. Speed means fast feedback loops from users/engineers and fixing bugs quickly. Speed, done right, increases quality.
8/ The real downside is short-term-ism. Focus on speed often leads to focus on short time horizon. You can make strategic/long-term mistakes and then you execute quickly and reach a gnarly local maxima. Obvious example of this was the move to HTML5 on mobile, a recurring theme.
9/ @the_prion then pressed us on personal/concrete anecdotes to expand on this question. @floydophone hopped in to talk about *another* mobile project gone awry. Facebook Home.
10/ Facebook Home, when it launched, was a customized lock screen/launcher with a special phone from HTC. It was actually a pivot from a previous, much more ambitious project to build an entire mobile OS. It was a beautiful product but unsuccessful in the market.
11/ The company had taken the playbook from the product codebase and used it to build a mobile OS. It didn't work very well. The company couldn't figure out how to rapidly iterate to a high level product. It end up being years late to market.
12/ This was a classic mistake of companies taking their founding myths (especially ones around process) and applying them to new/different problem domains. This happens all the time across many companies. This is a time it backfired and didn't work at all.
13/ My example was more personal: the native SDKs for GraphQL. The bulk of my career was working on the stack leading up to GraphQL, GraphQL itself, native SDKs for GraphQL, and open-sourcing GraphQL. GraphQL for Android most problematic chapter in that story.
14/ The first native SDK was in iOS (early 2013). I was able team up with amazing iOS talent (👋🏻 @adamjernst @ScottWolchok). We made really positive impact pretty quickly. The decisions we made paid dividends for years, as our data stack had a great foundation.
15/ Aside: this was all the more sweet and delicious since it involved extirpating an ORM (CoreData) from the system. ORMs are, nearly always, terrible for large systems.
16/ I then moved onto Android and executed a similar playbook. Take the lessons from iOS, and then focus on moving quickly by iterating on current architecture and towards a structure similar to the iOS one.
17/ I didn't realize that a) the current codebase was built by Java folks, not Android folks and b) that the constraints of iOS versus Android were wildly divergent. I just started to execute without properly examining the current assumptions and my assumptions.
18/ I was able to execute quickly and get some short-lived wins. However foundational mistakes were made, and it took years and entire teams to unwind them. The core problem was very difficult so it still might have taken a long time, but the initial decisions made it worse.
19/ Even in a move fast culture, it's appropriate to step back and do some Hammock-driven development. (see: ) Once you do start executing, move fast applies again. Also during brainstorming building prototypes for validation is good.
20/ On the whole @floydophone and I still defend the biases of "move fast" culture. But it has its potential downsides. I actually prefer the term "velocity" to "fast" these days because it implies a direction, not just a magnitude.
21/ Thanks for reading! Lots of other topics to come: open source project within commercial companies, product versus technical strategy, motivating engineers, code ownership, relationship between infra and product teams, monorepos, etc.
