“Communication is a sign of dysfunction.”
– Jeff Bezos, via Brad Stone, The Everything Store
Slack is a great way to destroy a workday.
You can lose whole days hammering out details with coworkers across a few Slack threads.
But communication is the cost you pay for capacity—the bigger the team, the greater the costs.
And this is why big teams fail to deliver. As team size approaches the magic number1, team overhead overwhelms its capacity for meaningful work.
🌐 For 𝑛 people, communication costs approach 𝑛²
our research has shown that the number of performance problems a team encounters increases exponentially as team size increases.
– J. Richard Hackman, Leading Teams: Setting the Stage for Great Performances
The cost of shooting off a Slack message is darn near zero.
But multiplying that cost by each person on your team adds up. And for each new person, you don’t add one connection—you add a connection for each person on the team.
In his 1975 book The Mythical Man-Month, author Fred Brooks formulates the communication costs of adding a new team member—a triangle number: 𝑛(𝑛-1)/2
The situation devolves quickly:
- Three people: 3 connections
- Four people: 6 connections
- 12 people: 66 connections
- 150 people: 11,175 connections
Metcalfe’s Law, originally intended to describe the value of communication networks, also describes connections among team members: the number of connections in a network is proportional to the square of the number of connected users of the system.
🍕 The mythical two-pizza team
Oversimplifying outrageously, we state Brooks’s Law: Adding manpower to a late software project makes it later.
– Fred Brooks, The Mythical Man-Month
Amazon uses the two-pizza team rule.
The intention is that the ideal team is small enough to feed with two pizzas—a highly variable measure. But a more straightforward way to say this is: about ten people.
🐉 Here be dragons.
Max limits on team size only thwart communication problems when teams are autonomous.
Cross-team dependencies obfuscate lines of communication. If teams are interdependent, they’ll still need to communicate. Regardless of what the org chart says, when two or more two-pizza teams depend on each other: you’ve got a bogged-down MegaTeam™.
Only small, independent teams with the power to build and deploy software can avoid the scourge of communication overhead.
7±2 per Miller’s Law↩︎
To see posts by date, check out the archives
To see posts by date, check out the archives
This week, we discovered that GitHub.com’s RSA SSH private key was briefly exposed in a public GitHub repository.
– GitHub’s “We updated our RSA SSH host key” blog, 2023-03-23
GitHub private repos lull us into lazy thinking.
We cram our secrets into git, then shove it off to the most expansive code forge in the history of humanity, and most of the time: everything’s fine.
But GitHub’s ssh host key leak last week demonstrates that private repos are, at best, private-ish.
Secrets get out. 🦖 Life finds a way.
How repos become public 💀
There are oodles of trivial ways you can spill your git secrets to the world.
- 📢 Publish your
.gitdirectory – Exposing the entire history of your code through server misconfiguration or deployment mistakes is alarmingly. common. - 🎣 Get phished – Even cool kids can have their passwords stolen. Examples in the wild:
- 🥄 Bad fork – Especially true with the GitHub/GitLab model—a developer forks a private repo and makes it public. Examples in the wild:
- 🖱️ Click the wrong button – You’re a handful of button clicks away from making a private repo public—miscommunication or confusing UI can leave you exposed.
Move fast, leak things 🚰
Most of the people at GitHub and GitLab are humans. And humans make mistakes (especially when they’re on a deadline).
Back in 2016, GitHub had an incident where private repos exposed to unauthorized users.
And GitLab has had at least three incidents matching the search “GitLab+Private repos” in the Common Vulnerabilities and Exposures (CVE) database (1, 2, 3).
Mitigations 🛠️
In the spirit of blame-aware postmortems—what can we do to fix this?
Easy fixes
- Keep your
.gitdirectory to yourself. Avoid deploying it. Configure your webserver to deny access to it if you do. - Setup two-factor authentication, like, Right. Now. Bonus points if your second factor is a hardware key.
- Audit your access control on your forge of choice.
Impossible fixes
It’s impossible to prevent a zero-day that exposes your private repo.
So, if you’re worried about it: stop putting sensitive data into private repositories.
Especially the kind that would damage your reputation if it got out:
- Passwords/production credentials
- Personally identifying information (PII) of users
- Any code, data, or metadata you expect to be permanently private
You can set a policy and ensure developers use secret scanners as pre-commit git hooks. Inject secrets into your application at runtime.
Beyond runtime secrets? Keep that junk out of git.
To see posts by date, check out the archives