Symphony Apps Development logo — teal interlocking S monogram beside the studio wordmark
All writing

A definition of done that includes deletion

Feature flags, migration shims and temporary compatibility code accumulate quietly. We started treating their removal as part of the ticket, not a separate one nobody files.

Category
Process
Reading time
5 min
Published
10 Jul 2026
Topics
Process, Engineering, Delivery

Every team we have worked with has a graveyard of feature flags still in the codebase for a launch that finished a year ago, still being evaluated on every request, still theoretically toggleable to a state nobody wants.

Why cleanup tickets do not get filed

The flag or the shim was necessary to ship safely, and by the time it is safe to remove, the team has moved on to the next thing and removing it delivers no visible feature to anyone. It competes for sprint time against work a client can see, and it loses that competition every time unless something forces the comparison to be explicit.

What we changed

The ticket that introduces a temporary flag, shim or dual-write path now has a second, linked ticket for its removal, created at the same time, with a target date rather than an open-ended "eventually". The removal ticket does not need to be done immediately — it needs to exist and to be visible in the same board the feature work lives on, so it competes honestly rather than being forgotten.

  • The flag ticket states its own removal condition — "remove once the new checkout has been at 100% for two weeks with no rollback" — rather than leaving that judgement to whoever eventually notices the flag.
  • A recurring review, monthly, of flags older than their stated removal condition, owned by whoever is on rotation that month rather than by whoever happened to write the flag.
  • Migration shims get the same treatment — dual-write code, compatibility adapters, anything that exists to bridge an old shape to a new one during a transition.

The cost of not doing this

Old flags are not neutral clutter. They are branches in the code that nobody is testing deliberately any more, which is exactly the kind of path where a defect sits quietly until an unlucky combination of conditions hits it.

Code written to be temporary that outlives its purpose is not technical debt in the usual sense. It is a decision nobody is making any more, still running.

What this looks like a year in

On the project where we have run this longest, the number of active flags has stayed roughly flat instead of climbing, and the ones that remain all have a stated, current reason for existing rather than an archaeological one. That alone made a recent security review considerably faster, because reviewing dead branches wastes exactly the kind of time a real audit does not have to spare.

Tell us what you’re trying to ship

A first call is thirty minutes and costs nothing. Bring the problem, not a spec — working out what to build is the part we are good at.

Or email office@symphonyapps.ro. We reply within one business day, in English or Romanian.