Legacy
summary
Argues legacy should mean lasting value and says most delivered business software lives about five years while Joel Spolsky claims it takes ~10 years to become “good.” Uses Twitter’s fail whale as proof that shipping matters, and cites a GE mainframe that outperformed replacements. Recommends tiny replaceable components, immutable deployments, disposable nodes, constant monitoring and practiced recovery instead of test-only confidence, regular rewrites of small services, and operational chaos testing with Netflix’s chaos monkey and Pinterest-style spot instances under a microservices approach.
AI-written summary · about
chapters (16)
- 0:00The pain of rewrites
- 2:42Redefining legacy software
- 7:11The industry's failure rate
- 9:35How to create lasting code
- 14:56Lessons from old mainframes
- 16:51The importance of shipping
- 19:26Software as a living organism
- 22:14Homeostasis and small parts
- 26:09Designing for disposability
- 30:17Regulating the system
- 31:46Immutable infrastructure
- 34:47Autonomy and coupling
- 36:22Embracing failure
- 37:00Monitoring and practice
- 40:07Automating homeostasis
- 43:48Conclusion
related talks
53mLegacy: how to win the race. Viktor Polishchuk. Java Fest 2020 Online
01h 00mThe Influential Software Engineer
49mLessons from a Project with a 2001 Commit
38mWriting Code That Lasts Forever
41mFirst Things First
47mGet old, go slow, write code!
01h 01mLessons from a lifetime of doing, teaching, managing, and leading technical development
33mWhat it takes to become a great developer!