“Procrastination attracts us because of hyperbolic time discounting: the immediate (guilty) rewards are disproportionally more compelling than the greater delayed cost. Procrastination is the reward itself.
An MIT professor found that when he allowed his students to give themselves their own homework deadlines, they would artificially restrict themselves to counter procrastination. However, they did not set deadlines for optimal effectiveness. I am personally a huge procrastinator and it’s always a pull between rational logic (giving yourself the most time by choosing end dates as the deadline), and your past experience saying you will put it off so force yourself to start early.”
At the same time, while it is inefficient to start late, but one should not try to start earlier than necessary. The task will occupy your mind longer and especially if you don’t like to do the work, it will stress you longer. The task does not become more difficult if you put it off until you need to do it. It just gets longer, because you will allow interruptions (there’s still time, so…).
Bigman2003 on SlashDot quotes this from his personal experience
” I manage a small programming team, and one of my jobs is to set up deadlines. The nature of where we work means that we don’t really HAVE deadlines at all (gubment) but we need to make progress. So, I impose deadlines on my team. Usually they are fairly aggressive, but we always meet them. Two days before the last deadline, my team was all working frantically trying to get things done. One of the guys asked, “Why the hell did you make the deadline so early? Why not just push it out two more months?”
My answer was the same as always: “If I had pushed this deadline out two months, we’d be going through this same exact crunch time, just two months later.” It’s just a fact, if we have six months to do a job, we’ll finish in exactly six months. If we’re given 12 months to do the same job, we’ll finish in exactly 12 months.”
I have observed two things. If the imposed deadline is shorter than the time actually needed to do the job, then the job will appear to be finished (i.e., people will say they are done), but there will be many things missing. Later, people will say “Oh, we were all under a tight deadline, so I guess we must have forgotten to do that”.
More interestingly, if the deadline is longer than the time actually needed to do the job, I have observed that the job is done early. But (and this is an important but), all of the functionality is actually there.
To perform this experiment for yourself, I suggest that you take several small problems (small bugs are good for this). Try to find problems that will take from 1/2 a day to a day. Assign deadlines ranging from 2 hours to 3 days. Record the amount of time it actually takes to do the work. Then do code reviews of all the work.
I think you will find the experiment very instructive.
I have found that when there is always work in the queue, there is no point to setting deadlines. Instead it is better merely to estimate the work (so that you can make predictions). It is also counter productive to measure the amount of time each task takes (otherwise people will cut corners in order to meet some kind of unreasonable expectation, sometimes self imposed). Instead, just keep a rolling average of how close your estimates are to reality (i.e., we’ve gone 10 days and we’ve finished 11 days of estimated work, therefore we are going at 1.1x our estimated rate). This gives you predictability without the negative side effects of measuring too closely. IMPORTANT: Don’t complain or cheer if the work rate is different than the estimated rate. This is to be expected. The information is only to allow you to communicate progress with management.
In every case that I have implemented this (and obviously this isn’t my idea — it’s standard practice in many shops), productivity, quality and predictability have all improved. It’s worth a try
Another reader winknerd suggests the following tips for a geek on how to beat procrastination