An Optimistic Proposal for Making Horrible Code... Bearable
summary
An attempted rewrite moves only about 10% of revenue after eighteen months while the old monolith still pays; tests once take four days on a laptop (reduced to 4–5 hours on many machines) with ~10% flapping, a million lines of Ruby and a 6,000‑line user model. Practical fixes: measure with rake stats and a custom spec formatter, enforce RuboCop ratcheting thresholds, delete useless flaky tests, extract service objects and split high‑churn files until things are steadily less terrifying.
AI-written summary · about
chapters (19)
- 0:00Start
- 5:43changing code breaks completely unrelated tests
- 5:59good luck merging your code style PRS
- 6:29we can't trust the test suite
- 7:04run like hell
- 7:31learned helplessness
- 9:18badness is unevenly distributed
- 11:11bundle exec rake stats
- 14:21fixing the code
- 17:47act
- 18:58breakage is going to happen
- 20:00foolproof test fix
- 20:28delete them
- 21:18make writing new tests fast
- 22:05eliminate dynamic code
- 24:14behead the dragon
- 27:15churn
- 28:291. name the evil 2. stop the bleeding 3. strategically improve
- 28:454. focus on the process
related talks
48mRefactoring from Good to Great - A Live-Coding Odyssey
36mWorking Compassionately with Legacy Code
34mSimple and Elegant Rails Code with Functional Style
42mThe world runs on bad software
32mKeeping your code strong
09mMicrotalk:A House of Cards - The Perils of Maintaining a 7-Year-Old Codebase
36mDeath by a thousand commits
17mRewriting Code and Culture