Rewriting Code And Culture
summary
Songkick rewrites a growing Rails monolith into a set of HTTP services and independent front-end pages, starting with the highest-value event page and deploying page-by-page on master so users always see working releases. The team replaces controller logic with page and component classes, keeps only a few end-to-end checks, and trims the test suite so the Rails test run is build time under a minute (integration suite ~5 minutes). The rewrite finishes (Feb 2012), velocity and releases per month increased.
AI-written summary · about
chapters (28)
- 0:00Introduction and speaker intro
- 1:08Songkick’s legacy code problem
- 2:14The monolith and rewrite decision
- 3:38Service-oriented architecture plan
- 4:21Lessons learned from the rewrite
- 5:46Defining the end state
- 6:50Starting with the riskiest feature
- 7:53Focus on one main goal
- 8:56Defining project scope and deadline
- 10:23Deleting features to move faster
- 11:50Validating assumptions early
- 12:53Speeding up the build process
- 14:41Faster releases and monitoring
- 15:43Changing the product development process
- 16:24New front-end architecture demo
- 21:52Decoupling domain models
- 23:35Rewriting without downtime
- 24:39Cultural changes at Songkick
- 26:05Cross-functional product teams
- 27:11Early developer involvement
- 28:16Pairing designers with developers
- 29:19Key takeaways and collaboration
- 30:46Q&A: Starting with the riskiest feature
- 31:31Q&A: Service standardization
- 32:15Q&A: Backup plan and stress
- 33:01Q&A: Regrets and doing it earlier
- 33:44Q&A: Selling technical debt
- 34:47Q&A: Crisis as catalyst
related talks
29mHacking Development Culture: Treating Developers As People
42mSo You Want To Rewrite That...
01h 05mLegacy Rails Q&A
40mBeyond your daily coding
29mBoot the backlog: Optimizing your workflow for dev happiness
38mOur Fight Against Super Bad Patterns in Legacy Rails Apps
28mEmpowering a Performance Culture
28mHow To Finish What You Start: Lessons From Actually Shipping..