By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.
Y CombinatorThings That Don't Scale, The Software Edition – Dalton Caldwell and Michael Seibel
Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.
At a glance
WHAT IT’S REALLY ABOUT
Famous Software Companies Succeeded Through Dirty Hacks That Didn't Scale
- Seibel and Caldwell explain Paul Buchheit's 90/10 solution idea, getting 90% of the benefit for 10% of the work, and illustrate it with the early days of Gmail.
- Caldwell shares a firsthand story of Facebook scaling by running a separate PHP, MySQL and Memcache setup per school, plus the Friendster versus MySpace shortcut on the extended network feature.
- Seibel describes Twitch's hacks for handling 20X traffic peaks, expensive bandwidth and translation, including static pages, pre-propagating streams, an ISP-blocking message and crowdsourced translation.
- Caldwell recounts a secondhand story of Google's stale index, which led to MapReduce, to show that scalable infrastructure is built only after a product has earned users.
- The closing advice is to launch, 'turn the water on', fix what breaks, and not let perfect be the enemy of the good.
IDEAS WORTH REMEMBERING
5 ideasAim for 90% of the benefit with 10% of the work
Paul Buchheit pushes founders with this idea whenever something seems too hard or slow to code, and Seibel and Caldwell say founders don't love hearing it.
Constraints often look like clever growth hacks in hindsight
Gmail's invite system was not a virality plan but a response to having too few servers, as Caldwell and Seibel describe it.
Avoid solving the hardest scaling problem if you can sidestep it
Facebook gave each school its own code and databases rather than scaling one huge users table, and it took years to build a global one.
Cheap shortcuts can beat complex engineering
MySpace labeled people as 'in your extended network' while Friendster tried to scale live MySQL calculations, and Twitch used a static-page button and website-to-video-system signaling.
Good decisions often come under duress
Caldwell notes that many of the best product decisions are made fast, such as when the site is down at 8 PM, as with Imeem's video-file hack and Twitch's free peering ISP message.
WORDS WORTH SAVING
5 quotesIf you have a house and it's got full of pipes, and you know that some of the pipes are broken and they're gonna leak, you can spend a lot of time trying to check every pipe, guess whether it's broken or not, and repair it, or you can turn the water on.
— Michael Seibel
I think people are always surprised that that's basically all startups do is just turn the water on, fix what's broken, rinse and repeat. And, like, that's how big companies get built.
— Michael Seibel
I do think this is a recurring theme, is a lot of the best product decisions are ones made kind of fast and kind of under duress.
— Dalton Caldwell
You earn the privilege to work on scalable things by making something people want first.
— Dalton Caldwell
Don't make the perfect the enemy of the good. Just try to figure out any kind of way to give something pe- somebody something that they really want, and then solve all the problems that happen afterwards.
— Michael Seibel
High quality AI-generated summary created from speaker-labeled transcript.
