Write Code That's Easy to Delete: The Art of Impermanent Software
The article advocates for designing software with deletion in mind rather than prioritizing longevity and extensibility. It argues that most code doesn't last and that over-engineering for permanence reduces adaptability. Instead, code should be modular, isolated, and bounded to allow for easy removal or replacement.
- ▪Most features in software are changed or removed within months, contradicting the assumption that code must be built to last.
- ▪Code that is easy to delete is typically isolated, has clear boundaries, and avoids deep dependencies or global state.
- ▪Design practices like feature flags, interface abstractions, and the strangler fig pattern support reversibility and safe deletion.
- ▪Duplication, while often discouraged, can increase module independence and make deletion safer.
- ▪Abstractions should be used not just to reduce repetition but to create boundaries that enable change or removal without widespread impact.
Opening excerpt (first ~120 words) tap to expand
try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 1002243) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Adam - The Developer Posted on May 2 Write Code That's Easy to Delete: The Art of Impermanent Software #webdev #architecture #programming #productivity We obsess over making code last. Maybe we should obsess over making it leave gracefully. There's a quote that's been living rent-free in my head for years: "Write code that is easy to delete, not easy to extend." — Tef, programming is terrible The first time I read it, I pushed back.
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at DEV.to (Top).
Discussion
0 commentsMore from DEV.to (Top)
