"Will We Make the Deadline?" Check the Code, Not the Ticket
By Fahad Ijaz · · 5 min read
Ask any team 'are we going to hit the date?' and the answer usually comes from scanning due dates in the tracker. But a due date is a claim about the future attached to a ticket, and it suffers from two problems at once: it's often already out of date, and it says nothing about whether the work behind it actually exists yet. A deadline you're panicking about might already be met. A deadline that looks comfortable might be attached to work that hasn't started.
A Date Is Not a Status
The trap is treating the date and the progress as the same fact. They're not. An item due Friday that already shipped is not a risk — it's a closing formality. An item due next month with nothing in the code yet is the thing that should be keeping you up at night, even though its date looks safe. You can only tell the two apart by grounding the deadline in what's actually built, not by sorting tickets by due date.
The Conflicting-Dates Problem
Real deadlines rarely live in one clean field. One shows up in the ticket title, another in the description, a third buried in a comment three weeks later that quietly moved the date. When those disagree, the worst thing a tool can do is silently pick one and present it as fact. The honest approach surfaces every date, says where each came from — title, description, or whose comment — and in what order they were stated, so a later comment that revises an earlier date is flagged as the likely current one rather than averaged away.
Grounding the Deadline in Reality
For a real deliverable, the useful answer pairs the date with the state of the work: does the code show this as done, partly done, or not started? That reconciliation is what turns a list of due dates into a plan you can act on. It also filters out the noise — a throwaway test ticket or a placeholder doesn't need a code investigation, and treating it like a real deadline just adds panic. The goal is a schedule you can trust: real items, real dates, real progress.
What Changes When You Do This
Instead of a due-date list that mixes finished work, live risks, and abandoned placeholders, you get a reconciled view: what's genuinely at risk because the code isn't there yet, what's effectively done and just needs closing, and where two dates disagree so nobody's working off a stale number. That's the answer a senior engineer would give you after an afternoon of digging — which of these dates actually matter, and why.
The Takeaway
Deadline risk measured off ticket labels is a guess with a calendar attached. Measured against the code — and honest about conflicting dates — it becomes something you can plan around. The date tells you what someone hoped. The code tells you what's true.