How to delete everything: The clean-slate approach to technical strategy
summary
Clean-slate exercises uncover concrete options: a legacy Python service audit reveals 31 individual functionalities, shows which logs and partners break, and surfaces a viable lift-and-shift within time constraints that actually gets implemented instead of a risky do-nothing. Sessions take an hour, use simple diagrams and name-denial descriptions to strip architecture bias, produce rough timelines and API touchpoints, and convert vague refactor fear into measurable migration scopes and incremental roadmaps that stakeholders accept.
AI-written summary · about
chapters (14)
- 0:00Clean-slate thinking
- 1:07Why delete working systems
- 3:16Refactoring vs rewriting costs
- 6:45Mental deletion without outages
- 7:27Productive clean-slate sessions
- 10:18Chaos engineering deleted services
- 12:25Hidden service responsibilities
- 13:49Legacy Python migration case
- 17:39Why no code deleted yet
- 18:21Revising biases after exercise
- 19:43Joe’s one-day refactor
- 20:45Ideal state vs reality
- 22:55Turning complaints to roadmaps
- 23:16Summary and call to action
related talks
57mTechnology mix: From legacy to clean architecture
38mDeleting Code Is Hard And You Should Do It
43mEverything You Need, Nothing You Don't: How Do You Actually Build a Lean Platform
18mTackling tech debt
54mGetting Unstuck. Strategies for Surviving in a Rapidly Changing Post-Agile World
29mDriving clarity in ambiguous projects
29mNo more tears from project nightmares
24mLessons from a Librarian