Parkinson’s Law says that work expands to the time allowed. I’ve seen that play out over and over. However, I’ve also seen a sort of opposite of Parkinson’s Law. Sometimes work gets done faster when you have more time for it.
Sometimes when I’ve planned a large block of uninterrupted, say going into the office when hardly anyone else is there, I get through my to do list in the first hour of the day. Knowing that I have plenty of time, I think more clearly and end up not needing the extra time. When that happens, I sometimes think “If I’d known this would just take 30 minutes to solve, I would have done it sooner.” But it’s not that simple. Just because it took 30 minutes on a good day doesn’t mean that it could have been done during just any 30-minute time slot earlier.
In his book Symmetry and the Monster, Mark Ronan shares a story along these lines. Ronan tells how John Conway worked on a famous mathematical problem. Conway and his wife agreed that he would carve out Saturdays from noon to midnight and Wednesdays from 6 PM to midnight for working on this challenge. He started one Saturday and cracked the problem that evening. Perhaps Conway would have been able to solve his problem by working on it an hour at a time here and there. But it seems reasonable that having a large block of time, and knowing that other large blocks were scheduled, helped Conway think more clearly.
My guess is that Parkinson’s law applies best to projects involving several people and to one-person projects that are not well defined. But for well-defined projects, especially projects requiring creative problem solving, having more time might lead to not needing so much time.
The surest way to go slow, in software development, is to cut corners while trying to go fast. There are countless examples of this style of infinite defect development resulting in massive schedule slippage and uncertainty. It’s not entirely surprising that having the mental breathing room of knowing that you have more than enough resources available to get things done “the right way” can lead to efficiencies which result in getting done faster.
The fascinating aspect is that such efficiencies may occasionally be on the scale of orders of magnitude rather than incremental differences. Perhaps more than occasionally.
It’d be great to see more research on this.
outstanding post!
shorter cook’s law: haste makes waste.
meanwhile: hurry makes worry.
i noticed that years ago
but have never typed it out till now.
While I do not consider myself to be highly productive, some people have marvelled at my (modest) productivity. Invariably, they are surprised when I tell them that I work fewer hours than they do.
I recognize this from myself. I tend to be more productive when I am relaxed and have plenty of time available.
The story about Conway is also told in Thomas M. Thompson’s “From error correcting codes through sphere packings to simple groups”.
In Denmark we have a saying that goes something like “The ultimate laziness is doing it correctly the first time” (or something along those lines). When you are in a hurry, you tend to cut corners and make mistakes that you have to repair later on.
Jan: There’s a similar saying here: “Slow is smooth, and smooth is fast.” I don’t think it is too widely known. I believe it comes from military special forces.
I’d say it sometimes is the result of two things:
0) There is a Minimum Productive Time Unit. There’s time to swap back in all of the things you had swapped out of brain-registers, and time to spin back down again and disengage from the problem. So far, this has been particularly true of me in software, and I’m not alone in this (there are lots of articles about why meetings and strict schedules for programmers can be very counter-productive).
1) Technical debt. You can make something work, or you can make a framework on which future work can readily build. You can kludge something together something that just barely works for the indented purpose, or you can spend more time to create something that will make furture extensions and efforts (relatively) straightforward.
(In some ways, programming and mathematics seem to be very similar. Math, it seems to me, is mostly building “programs” (proofs) out of logic. Though it’s commonly thought of the other way, since programming has a lot of basic maths in it (and less-basic maths when you know where and how to look. :) )
I usually work in blocks of time measured in a unit called “cigar,” approximately 3 hours. Advantages of this unit include that it can only be used in certain isolated and restrictive environments and its use entails certain physical manifestations that further reduce one’s probability of being interrupted.