When Your Codebase Is Nearly Old Enough To Vote
summary
Dreamwidth Studios maintains a fifteen year old web app with quarter million lines of legacy Perl, custom BML templates from 1996, and UTF‑8 handling implemented in 2001 that destroys later recovery. Upgrading Apache 1.3 to 2.0 takes six months and introduces fresh bugs; switching the frontend to Foundation has been ongoing for ~18 months and triggers picky user regressions. Expect duplicated search/admin systems, ancient browser workarounds, and a lot of archaeology before any rewrite pays off.
AI-written summary · about
chapters (15)
- 0:00Intro
- 2:02About Dream With
- 4:06Technical Challenges
- 6:58Opera workaround
- 8:09Old HTML
- 8:39Special Casing
- 9:33Old Bad Decisions
- 19:01What Code Comments Turn Into
- 19:23Should I Rewrite This
- 19:50Should We Upgrade Apache
- 22:42Should We Upgrade Foundation
- 27:39Pros of Rewriting
- 30:42Cons of Rewriting
- 35:11Should I Rewrite
- 36:15Future Proofing
related talks
09mMicrotalk:A House of Cards - The Perils of Maintaining a 7-Year-Old Codebase
35mMy Rails App is Old Enough to Drink: Over Two...
46mAncient Rails
36mWorking Compassionately with Legacy Code
43mModern Web Development in Perl
51mCode spelunking in the All New Basecamp
29mHacking Development Culture: Treating Developers As People
41mExploring the History of a 12-year-old Rails Application