What "done" should mean on an engineering ticket
Code complete and actually done are two different milestones.
"Done" gets defined inconsistently across most teams, which quietly causes a lot of the friction between engineering and everyone else. Code complete means the logic exists. Done means it's tested, it handles the failure cases, it's deployed, and someone other than the author has confirmed it does what was asked.
The unstated gap causes real friction
Skipping the gap between those two definitions is where most "it's done but it's broken" conversations come from — not from bad engineering, but from an unstated assumption about what done was supposed to include in the first place.
Write it down once
A definition of done, written down and agreed on once, removes that ambiguity permanently. It's a small amount of upfront clarity that prevents a recurring, low-grade source of friction for the life of the project.
Different tickets, same bar
The definition doesn't need to be identical for every ticket, but the bar needs to be explicit for each one — a small internal tool and a customer-facing payment flow reasonably have different testing and review requirements, as long as everyone agreed on that difference in advance, not after the fact.
- Code complete and done are different milestones — define both explicitly.
- Most 'it's done but broken' friction comes from an unstated definition gap.
- A written definition of done removes the ambiguity permanently.
Turning support tickets into your best product research
HAVE A PRODUCT IN MIND?
Tell us what you're building and where you need engineering support.