Parkinson's law states that work expands to fill the time available for its completion. It was first articulated by C. Northcote Parkinson in a 1955 essay in The Economist, satirising bureaucratic growth in the British Civil Service.
In software engineering the law manifests as scope and polish creeping up to consume whatever runway exists. Given three weeks to build a feature, the implementation takes three weeks. Given three days, it takes three days — and the result is often functionally equivalent because the extra time in the first case was spent on marginal improvements, over-engineering, and second-guessing decisions.
The law motivates time-boxing: deliberately setting short, firm deadlines for tasks to prevent indefinite expansion. Agile sprint cycles are partly a mechanism for forcing this. A two-week sprint with a fixed scope does not allow a feature to quietly absorb a fourth week of polishing.
It also explains why estimates tend to be self-fulfilling. If a developer estimates a task at five days and it could be done in three, the estimate creates the deadline, and the task takes five days. Better estimates (or no estimates, just small batches of work) reduce the effect.
Parkinson's law is related to Goodhart's law: once a time target becomes a commitment, behaviour optimises for hitting the target rather than for the underlying goal of shipping useful software efficiently.