Have you ever noticed how often you seem to finish a project, no matter how big or small, almost exactly when it’s due? Sometimes you’ll work harder than ever to get a seemingly gigantic project done in a week, and other times, you’re stressing at the last minute to finish up a speech that you’ve had a months to complete. You could be consistently finishing up at the last minute because you’re lazy, but Parkinsons Law gives us another explanation.
Parkinson’s Law as commonly referenced states that “work expands so as to fill the time available for its completion.” A more succinct phrasing also commonly used is “work expands to fill the time available.”
Basically, when you have a task at hand you will create enough work to fill up the amount of time that is allotted to that task. If you have too much time, you’ll somehow find more work to fill that time, whether it be through additional features or just plain procrastination. And if you’re in a serious time crunch you’ll eliminate anything that isn’t absolutely necessary to the completion of the project.
This is important to recognize in software development because when you are not restricted by time and/or money, it’s easy to create an endless amount of features or strive for what you perceive as perfection. This explains why some extremely bureaucratic companies take forever to release anything, and it’s why some startups with too much money on their hands take way too long to launch their first product.
We’ve definitely felt the effects of Parkinson’s Law, both positive and negative, while creating Wufoo. Being a part of YCombinator was extremely beneficial to us because we had about 8 weeks to create a working demo to show potential investors. This real time constraint forced us to cut out many features that were “must have” and only focus on what was critically important. There was no time to endlessly tweak the design or code, and it was much easier to focus on what was essential. Interestingly enough, we still haven’t released some of those “must have” features, so it’s possible that we still wouldn’t have launched without deadlines.
On the other hand, productivity took a hit after launching when we weren’t under such serious time constraints. We’ve continuously developed and improved Wufoo, but more time was spent on random improvements, tweaking, and tasks that were mentally stimulating rather than what was necessarily best for our software. We’ve recently gone back to a system with long-term and short-term deadlines, and we’ve already seen improvements in both focus and productivity.
F’ing Parkinson’s Law.
I think this applies to running also. No matter the distance, every run seems hard. Either because you make it harder by running faster, or you mentally fill your head up with negative thoughts. Yeah … tonight’s run sucked.
Good points. Nothing like an immovable launch-date to really speed things up. The trick is coming up with those launch-dates that aren’t just arbitrary!
I think the most difficult part is balancing that deadline between ‘motivational end-date’ and pushing towards a burn-out.
When assigning any deadline I always try to build a few days of delay into the timetable. It works best on smaller tasks but it can really backfire when one person in a group situation delivers late.