I once had a task I estimated at two weeks. Over a year later, it hadn't shipped. In the post-mortem, the two-week estimate turned out to be correct. What went wrong was that there was no deadline attached to it.
Without the deadline, the task didn't stay a two-week task. It quietly grew. I explored an unfamiliar language because it "felt like a good fit". I chose an experimental framework because it was "worth learning". I attempted system design in a domain I didn't yet understand, because "we'd need it eventually anyway". Each decision was individually defensible. Together they made a two-week task infinite.
Complexity is what fills the vacuum when there's no time pressure. This is a design fact, not a discipline problem.
Deadlines aren't oppression. They're a tool. They force the useful question at every branch: does this decision fit in the time I have? A framework you've never used doesn't fit. A speculative abstraction doesn't fit. A domain you haven't studied doesn't fit. The deadline eliminates them for you, without you needing willpower.
This matters more now than it did three years ago. In the AI-assisted era, code is nearly free. The old constraint (can I build it in the time available?) has dissolved. The new constraint is (am I building the right thing at all?). The absence of a deadline used to just delay a project. It now enables limitless exploration in every wrong direction, quickly.
The working rule I use: every task gets a deadline before I touch the keyboard. Two-week tasks are two-week tasks. If the deadline reveals that the task can't fit, that's the useful signal. Either the scope is wrong, or the objective is wrong. Both are cheaper to fix at the whiteboard than after four months of infrastructure work.
Deadlines are not about pace. They are about scope control by other means.
Drafted in January 2023
Updated for site in 2026