Parkinson's Law

This law shows a common problem with time management among developers. If a developer is given two weeks to complete a task that could be done in two days, the work will usually slow down, consuming most of that time. People might spend more time planning, bikeshedding minor details, or simply delaying the start of the work with the understanding that they have enough time.

Parkinson’s Law is often used to warn that loose deadlines reduce productivity, so teams should set clear, realistic time limits. However, managers must use it judiciously, combining Parkinson’s insight with realistic scheduling. If you compress timelines too much, you risk running into Hofstadter’s Law, which reminds us that work often still takes longer than expected, even with buffers.

A developer should write a module and is told, “Take as long as you need, maybe a month or two.” In many cases, the developer will not rush to finish it, perhaps experimenting with multiple implementations or polishing noncritical items. The same task, if given a one-week deadline, might have been completed in a week.

Agile teams sometimes apply Parkinson’s Law by time-boxing tasks. The fixed, short time box encourages everyone to focus on completing tasks before the sprint ends.

Similarly, if a meeting is scheduled to last all day, it often will. If the same activity were given a two-hour window, participants would likely focus and complete it within that time.

Parkinson’s Law was first described in an essay by Cyril Parkinson, published in The Economist in 1955, which initially described how bureaucracies expand over time. The phrase has since entered the lexicon of project management.

It’s not specific to software, but software teams often see it in action during projects.