Finish What You Start: Why We Avoid "We Will Fix It Later"

Every software team knows the phrase: "We will fix that later." It is said with good intentions. The fix is small, the deadline is close and later seems like a reasonable time. Then later arrives, crowded with new priorities, and the fix never happens. Multiply that by months and a codebase fills with small, known problems that nobody owns.

We work from a simple rule: when work is requested, we complete it in the same session. Not tomorrow, not in a fresh session, not next time. Here is why, and how we handle the cases where finishing really is not possible.

Deferred work has a hidden cost

When work is deferred, several costs quietly appear. The context that made the fix easy is lost: the person who understood the problem moves on. The problem may grow as new code builds on it. And the request itself may be forgotten, leaving the person who asked believing it was handled.

Finishing while the context is fresh is almost always faster than returning to it later.

Complexity is not a reason to delay

Large tasks can feel overwhelming, and "let's do this properly later" can sound responsible. Usually it is not. A large task can be broken into smaller pieces and started immediately. Starting reveals what is actually hard, which is far more useful than estimating it from a distance.

When we receive a big request, we break it down, plan the pieces and begin. Many hands, including AI helpers working in parallel, can make a large task manageable within a single working session.

When there is a real blocker

Sometimes work genuinely cannot be finished: an approval is needed, a provider is unavailable, a decision belongs to someone else or required access is missing. In those cases, we do not use vague language like "we'll circle back." We name the specific blocker, what is needed to clear it and who can clear it.

A specific blocker can be resolved. A vague deferral simply waits.

Finish includes the boring parts

Finishing means more than writing the main code. It includes the parts that are easy to skip: connecting the new feature to the screens that use it, updating documentation, adding a regression check, updating the handoff and verifying the result. A feature without those parts is not finished, even if it works in a demo. Our Zero Dead Code rule applies directly here: nothing new is left unconnected.

Parallel work makes finishing possible

Some requests are genuinely large, such as rebuilding a website, writing a library of articles or revamping every screen in a module. Those used to be the classic candidates for "later." Today, a lead can divide the work into independent pieces and let several helpers work at the same time, each on its own files, with shared rules and a shared checker. The lead keeps the pieces consistent, reviews the results and handles the parts that need the most judgment.

That approach turns a task that might have taken weeks of scattered effort into a focused push that finishes in one sitting. It only works when the pieces are truly independent and the rules are written down, which is why we invest so much in both.

Finishing well, not just quickly

Finishing in one session is not an excuse to rush. Every piece still goes through review, automated checks and verification. The goal is not speed for its own sake; it is to avoid the slow decay that sets in when work is left half done. A finished task with honest notes about its limits is far more valuable than a perfect plan for a task that never gets completed.

Small things count too

The rule applies to small requests as much as large ones. A typo spotted during other work, a confusing label, a missing link: if it is in the area we are working on and the fix is clear, we fix it now. Small improvements made in passing add up to a product that feels cared for.

Report what is left

Sometimes a session ends with work truly remaining. When that happens, the remaining items are listed precisely, with their status and what each needs. That turns "later" into a concrete plan someone can pick up. You can read about how we write those plans in handoff notes.

Respecting the person who asked

At heart, this rule is about respect. When someone asks for something, they are trusting that it will be done. Finishing, or explaining exactly what stands in the way, honors that trust. Quietly deferring it does not.

Frequently asked questions

Is it bad to defer work to a later time?

Deferred work often loses context and gets forgotten. Finishing while the context is fresh is usually faster and more reliable.

What if a task is too big to finish at once?

Break it into smaller pieces and start immediately. Starting reveals what is actually hard, and parallel help can speed up large tasks.

How should blockers be reported?

Name the specific blocker, what is needed to resolve it and who can resolve it, rather than using vague promises to return later.