The Inevitable Undeletion Request
Description
This two-part meme captures a classic developer frustration. The top text reads, 'When the client asks for the feature that you deleted from the project, because they said "We will never use it"'. Below the text is an image of a female anime character with brown hair in a ponytail, sitting at a desk with a laptop. She has a wide-eyed, panicked expression and a strained smile, while simultaneously punching the wall behind her with enough force to cause it to shatter and crack dramatically. The image powerfully visualizes the internal rage and despair a developer feels when a client reverses a major decision. The scenario is a common one: a stakeholder confidently declares a feature useless, the developer deletes the corresponding code to clean up the project, and then, inevitably, the stakeholder changes their mind and asks for the feature back. This meme resonates with experienced developers who understand that deleting code is easy, but restoring it (and its dependencies) can be a significant, unforeseen task, highlighting the importance of robust version control and the communication gap between developers and clients
Comments
12Comment deleted
This is why my commit message for deleting a feature is 'temporary code removal' and I don't squash the branch for at least two sprints
Stakeholder: “We actually need that feature we killed during the YAGNI purge.” Me: “No problem - let me just necromance commit 3f4d7c from 2019, thread it through today’s microservice mesh, and pray the schema migrations don’t reenact Pompeii.”
The only thing more permanent than a 'temporary workaround' is a feature the client swore they'd never need - right up until the moment you finish purging it from version control, including all the branches where it might have survived
This is why senior engineers maintain a 'graveyard branch' with a 90-day retention policy for 'definitely unused' features. Because in software development, 'we'll never use it' has the same energy as 'it works on my machine' - technically true until the moment it catastrophically isn't. The real pro move? Implementing feature flags from day one, so when the client inevitably asks for that 'never needed' functionality at 4:45 PM on Friday, you're just toggling a boolean instead of archaeology-ing through six months of git history while your wall develops structural integrity issues
YAGNI: the principle clients treat as a suggestion, not a contract
Schrödinger’s requirement: YAGNI in grooming, P0 the moment git gc finally prunes the branch
The fastest way to summon a P0 is a PR titled “remove unused feature” - keep it behind a flag and a deprecation window, or watch requirements achieve instant consistency the moment you merge
But Git remembers everything 🤷♂️ Comment deleted
💪 Comment deleted
Use feature flags, Luke Comment deleted
and support unnecessary code, that is so simple to keep it up to date Comment deleted
That unfortunately happened to me once!!! Comment deleted