Going Evergreen
summary
Claim: large long-lived Ruby projects can stay easy to change instead of decaying into Brownfield by applying concrete practices. Evidence: two projects recover to “Evergreen” after about one to two years of steady work, a seven-year Pivotal project sustains healthy design, and pairing plus TDD plus Sandy Metz rules prevent technical drift. Tools and tactics: SOLID-guided refactoring, dependency injection, query objects, hiring metrics (communication, motivation, self‑awareness). Built outcome: a revived codebase run by mostly junior engineers that remains cheap to reimagine.
AI-written summary · about
chapters (15)
- 0:00Intro
- 0:19Going Evergreen
- 3:19Why do fields go brown?
- 7:20Borrowing
- 8:47Technical Drift
- 9:47Adjusted Initial Velocity
- 10:07Realistic Goals
- 10:49the Brownfield progression
- 11:29total features = area under graph
- 12:42Maintenance
- 21:49Actionable for everyone
- 23:32After a year, we were evergreen
- 29:26How should we choose our team?
- 29:40Weird Affective Metrics (that work)
- 35:42But what about tech skills?
related talks
29mThe End of Fun
44mBuild to Last...
33mBuilding resilient frontend architecture
27mLaying the Cultural and Technical Foundation for Big Rails
35mSurviving the Framework Hype Cycle
44mAvoiding the pitfalls of rebuilding software
45mChanging attitudes toward legacy code
17mHow to deal with technical debt in fast-paced environment