Project Deadline
Last year I worked on a software project that was suddenly elevated in importance. I was asked how long would it be before it was finished. I casually responded, “About two weeks if I can get the rickety development hardware to work.” This very rough estimate became a deadline almost immediately and caused a great deal of pressure to come my way. Part of the problem was random hardware errors that caused grief for my software. Eventually another programmer was drafted in to help with the software and two engineers tracked down the source of the hardware errors. During this fiasco I pondered the difference between an estimate and a deadline and how they became closely married together.
Deadline Origins
It was brought to my attention by Mirriam-Webster that the first meaning of deadline is “a line drawn within or around a prison that a prisoner passes at the risk of being shot.” It was a real line, drawn in the dirt in Civil War camps. The prisoners were told that if they crossed the line they were dead. It was soon called the dead line. The term was then applied to other situations with strict boundaries. Newspaper editors started to set deadlines and other writers began to use the term. Deadlines are now essential not just for reporters and other writers but in every kind of activity.
Software Development Deadlines
When an estimate morphs into a deadline the effectiveness of the software development declines and puts excessive pressure on developers, making their lives miserable. Working more hours does not necessarily result in more production and applying pressure to workers is not the optimum way to motivate. A deadline is often an arbitrary date set by someone who is not familiar with the project.
A good software team should already consist of motivated people. People cannot be pressured to think. Clear thinking does not come this way. Likewise forcing people to work harder results in short term productivity gains at the expense of quality which has to be corrected later. Working overtime to meet a deadline can cause staff burnout and does nothing to improve inefficient processes. Excessive overtime disrupts personal lives and causes employees to run errands on work time.
Refining Estimates
Updating estimates should be a normal part of the process and encouraged by management. Refining is a better word because it implies a normal process of improving on the initial estimate. Estimates will take into account what is to be done and at what rate and allowance made for requirements added or subtracted. Risks can be identified and accounted for.
Reality should never be at the mercy of wishful thinking. If on my project, estimation as a continuous process of refinement was the norm much of my grief (and management’s) would have been avoided.
Postscript
I did indeed finish my project though it took longer than two weeks. I was compensated with the equivalent time off for the hours of overtime I worked. Probably my biggest lesson learned is to pad my estimates until such time as Estimate and Deadline get a divorce. Well my friend that is all, I have a deadline to meet.
About the Photo: This is Andersonville, one of the most notorious southern prisoner of war prisons in the Civil war. This is in the inside of the complex. There was the wall (the logs in the background) and the fence, which was called the deadline. Soldiers had orders to shoot anyone who crossed the line. Photo Credit: upturnedface
Thanks for posting the article, was certainly a great read!
I agree with your methodology of padding an estimate. You also pointed out the grief of management, which is where I believe the problem “lies” – pun intended. Management is usually grief stricken because of self-imposed deadlines, having committed to someone up the chain-of-command based on the estimate received.
Good article.