Learning from Giants #11

The curious absence of scrum at Big Tech, Google's code coverage best practices, Mission, Strategy and Tactics, Figma's multiplayer technology, and Amazon's DynamoDB paper.

👋 Hi, this is Mathias with your weekly drop of the 1% best, most actionable, and timeless resources to grow as an engineering or product leader. Handpicked from the best authors and companies.

Did a friend send this to you? Subscribe to get these weekly drops directly in your inbox. Read the archive for even more great content. Also: I share these articles daily on LinkedIn.

---

How Big Tech Runs Tech Projects and the Curious Absence of Scrum

Project management and leadership is such a complex topic. The main reason: it's not a one-size-fits-all, because not all companies can afford to hire FAANG-level engineers, and all situations aren't equal.

Yet if you're in a leadership position at a tech company, you must reflect on that:

Ben Erez @ViableBen

In >1 year as a PM @ Facebook I've created zero tickets/tasks. We don't do sprints either. PMs here focus on vision, strategy & partnerships. Less on project management & tasks. Engineers carry most of the project management responsibility & create their own tasks. It's great.

"Scrum got in the way of shipping on a daily basis."

And even without rockstar engineers, there is a world of alternatives to POs and scrum.

"Competent, autonomous people need less structure to produce reliable, high-quality output."

"Leveraging competent teams comes through giving them freedom."

📗 Gergely Orosz's article is one of these articles so packed with excellent content that I can't even summarize it. Honestly, I'm almost ashamed to have tried! Please don't stop at these quotes and read the post, reflect, read it again, and build a new scrum-less world!

---

Google’s Code Coverage Best Practices

There are few tools in software development that are as controversial as code coverage. Why?

1. It's highly situational;

2. It is sometimes seen as just a number.

Let's go back to first principles. Tooling exists to prevent developers from having to execute the code in their heads when doing code reviews. It detects things that would take a human an hour to compute.

In that sense, code coverage is a significant benefit. But one that requires looking past the number.

"A high code coverage percentage does not guarantee high quality in the test coverage."

"But a low code coverage number does guarantee that large areas of the product are going completely untested by automation on every single deployment"

"In fact a lot of the value of code coverage data is to highlight not what's covered, but what's not covered."

But then there is THE polarizing question: what is the "ideal code coverage number"?

📗 Google testing blog's Code Coverage Best Practices describes how to use code coverage to keep a healthy codebase and improve it over time. It also gives Google's coverage guidelines, even though there is no universal "ideal" number. If you ever have that debate internally again, this article is a must-read for your entire party.

---

Fighting Organizational Entropy with Mission, Strategy, and Tactics

We hear those words daily, yet very few companies have clear, inspiring, and actionable Missions and Strategies commonly understood and shared.

If you're in that position, let's start with definitions.

1. Mission Statement

"A dense statement of the goal you are working to achieve over the long run"

2. Strategy

A path to achieve the mission, answering the question how in the most minimal way possible."

Emphasis on the most minimal way possible.

"The standard for something to be strategic is quite high; it means in order to succeed at our mission we must do it and we cannot succeed at our mission without doing it."

3. Tactics

"Tactical concerns are those which aren’t likely to prevent us from achieving the mission or enable it, but relate instead to how quickly we are able to do so."

📗 Andrew Bosworth is Meta's CTO and has been at the company since 2006. On this article, originally posted internally at Facebook in 2013, they clarify what Mission, Strategy and Tactics are. More than a lesson on such terms, "Boz" tries to give a common definition to align Facebook employees. Because as they say, it's not about using a word correctly, but rather having a common language across the company. That includes what Mission, Strategy and Tactics are.

---

How Figma’s Multiplayer Technology Works

Implementing multiplayer edition in an online editor is no easy task.

Although there are plenty of great live examples, like Google Docs, a great implementation still requires particular knowledge and thousands of lines of code.

And one way or the other, you'll end up using some form of Operational Transforms, or CRDTs, which stands for Conflict-free Replicated Data Types. Figma chose CRDTs for simplicity.

"CRDTs refer to a collection of different data structures commonly used in distributed systems. All CRDTs satisfy certain mathematical properties which guarantee eventual consistency."

📗 Figma's How Figma's multiplayer technology works is a well-illustrated explanation of the company's usage of CRDTs for its online design editor. Whether it's syncing object updates, object trees, or adding multiplayer undo, the number of challenges is significant, and each company has its own set of acceptable trade-offs that lead to different solutions.

Implementation of Undo in Figma. Source: Figma’s blog.

---

Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service

When learning about databases, once you know about the usual relational databases, there is one you cannot miss. Amazon DynamoDB.

"Amazon DynamoDB is a NoSQL cloud database service that provides consistent performance at any scale."

It's probably one of the largest scale transactional databases in the world.

"In 2021, during the 66-hour Amazon Prime Day shopping event, Amazon systems - including Alexa, the Amazon.com sites, and Amazon fulfillment centers, made trillions of API calls to DynamoDB, peaking at 89.2 million requests per second, while experiencing high availability with single-digit millisecond performance."

89.2 million requests per second. Only for Amazon-internal use cases.

A few architecture highlights:

• DynamoDB is a fully managed cloud service. There is no operational work whatsoever for users.

• DynamoDB employs a multi-tenant architecture.

• DynamoDB achieves boundless scale for tables.

• DynamoDB provides predictable performance. Read and write latencies are stable as datasets grow in size.

• DynamoDB is highly available. It's resilient to node or disk failures using replication and consensus mechanisms.

• DynamoDB supports flexible use cases. Its key-value store model can fit documents of varying types and schemas indifferently.

📗 Amazon's multiple DynamoDB papers explain how they achieved these capabilities at such a scale. The first one from 2007 describes Dynamo, a distributed NoSQL datastore created in the 2000s at Amazon that was the starting point for DynamoDB. The second one, from 2022, explains DynamoDB, a fully-managed, cloud-based evolution, and its development from the 2012 release to today. In 10 years, DynamoDB usage grew at an unprecedented speed, while the Amazon team added critical features every year like Secondary indexes, Streams, and Transactions.