What were they thinking?
summary
Argues that messy legacy Rails apps come from skipped refactoring, missing tests and ignored upkeep and proposes concrete fixes: automated tests and CI, regular refactoring, pair programming and disciplined pull‑request review. Recommends load testing, maintenance budgets, C4 architecture thinking, and continuous‑flow/no‑projects delivery. Mentions tools like Docker and AWS and specific versions (Rails 5.2.2, Ruby 2.6.1) as common pain points. Emphasizes persuasion skills to win resources for doing the work.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:04Acknowledging traditional country
- 2:33Legacy code regret
- 3:58Design refactoring and tests
- 5:02Upfront design importance
- 6:07Peer review and quality
- 7:31Maintenance and technical debt
- 9:00Leadership and business balance
- 10:51Discipline and mindset
- 11:56Continuous flow philosophy
- 13:22Agile movement evaluation
- 14:31Influencing stakeholders
- 16:20Art of persuasion
- 17:50New communication approaches
- 18:55Conclusion
related talks
23mLoving Legacy Code
28mRESCUE SQUAD: Rails Edition!
36mUsing Tests as a Tool to Wrangle Legacy Projects
32mRails Sustainable Productivity
31mIf it bleeds, it leads
36mWorking Compassionately with Legacy Code
01h 06mRailsConf Europe 08: David Heinemeier Hansson (37signals)
33mSo You Want to Start Refactoring?