Are you an upbeat artist or a sand bag engineer?

In my experience, many software developers do not know how to properly estimate a development task, regardless of how familiar they are with code streams, constituent technologies, or business processes.  We do not learn this in college, at least not in undergrad.  I place most developers into two categories, artists or sandbag engineers. 

The artists paint "rosey" pictures framed by hyper-positive and unrealistic delivery dates.  These developers mean well, and I would go as far as to say that they are actively trying to counteract the notion that all IT is slow.  However, the main problem is that these guys do not consider the nonproductive time that they have on a daily basis.  They do not consider activities that distract them from the estimated development task, including task switching to other development tasks.  In general, their estimates are nonscientific and based on their recall of previous experiences and anecdotal evidence.  In fact, these developers mostly do not realize that they "cherry-pick" the good experiences from the last development efforts and do not appropriately weigh the bad.

At the end of the day, artists have agreed upon, unrealistic deadlines that require herculean efforts to meet.  Sometimes they become temporary heroes to their managers or customers.  However, as I have said before, hero worship is not a long term, sustainable strategy.  And stories are legion of developers taking shortcuts when they ran out of delivery time.  Sooner or later the facade decays and these developers are exposed for the poor estimators they really are.  They are not bad people, just bad at estimating.

The sandbag engineers (a.k.a. sand-baggers) are not any better.  These developers pad their estimates from the beginning, regardless of the task size or complexity.  Some of them suffer from "Kirk/Scotty" syndrome.  They think that if they say it will take longer than it actually should, they will look good when they deliver way early.  This of course is a fallacy when examined by the astute manager.  Coming in way early is almost as bad is coming in way late.  The estimates are still wrong. 

Sandbagging is insidious.  It slowly undermines the trust and faith that managers and customers have in their developers.  There is nothing wrong with delivering early when the scope of a project is elaborated to the point of reduced effort.  However, more often than not, sandbagging is just a front-loaded risk mitigation strategy that is not grounded in scientific methodology or data.

In following posts, I will describe how I have performed estimation in the past, based on experience, scientific methods, and data.  It's certainly not a perfect process, but it places me on the spectrum between the artists and sand-baggers and my estimates are more accurate.