Taylor’s Guide to Big Rewrites
summary
Argues that a risky monolith rewrite succeeds when concrete practices guide it: a team of four spends 18 months building a separated data-collection service, runs a soft launch for new users in August 2021, and migrated 2,500 customers with repeatable, tested migration scripts and an enormous Postgres instance to handle heavy writes. Uses parallel set of models in the DB, freezes old assets, flips new defaults for new users, measures report parity, and changes team composition and values to restore cooperation.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 2:07Speaker background
- 3:29Taylor’s Scientific Management
- 5:57Monolith to microservices
- 7:02Choosing tools
- 9:08Contextual advice
- 10:13Failed rewrite and team
- 11:41Software isn’t a factory
- 12:28Taylor Swift’s lessons
- 14:57Distractions and ego
- 16:21Opportunities in hard times
- 17:45Pivoting to product
- 19:10Ship early and iterate
- 20:13Naming conventions
- 21:15Soft-launching
- 22:39Customer migration
- 23:40Handling feedback
- 25:04People over software
- 26:06Company values
- 27:29Four-day work week
- 28:30Rewriting the team
- 29:53Reflecting on mistakes
- 31:38Rewriting culture
- 32:41Final advice
related talks
41mThe big Rewrite
32mLegacy Code: Big Rewrite or Progressive Rejuvenation?
27mBig Rewrite Strikes Again
42mSo You Want To Rewrite That...
36mHow to sell a big refactor or rewrite to the business?
39mTaming Monoliths Without Microservices
01h 01mThree Rewrites, One Startup - An Architect’s Journey
24mHow to prevent a rewrite