Software Estimates - Over Estimate or Under Estimate?

Like most developers, I'm asked on a relatively consistent basis by project managers and clients to provide estimates of time and resources involved with completing a given task. Being the somewhat conservative person I am, I tend to pad my estimates - or simply put, overestimate. My rationale for doing this is to account for unforeseen events.

In an effort to improve my estimation skills, I've started reading the book "Software Estimation - Demystifying the Black Art" by Steve McConnell. Much to my interest, the third chapter - "The Value of Acurate Estimates" directly addresses the issue of overestimating vs. underestimating. The author points out that overestimation is the more common route that software estimators take for a simple reason - the ramifications of underestimating are much greater than overestimation. We can all probably do the math on this one.

Taking into account 2 factors, the first being that most estimates are overestimates and the second being Parkinson's law, one obvious result emerges. Project stakeholders catch onto this, and this is where pressure comes into play - pressure to squeeze out that extra time that was included to 'pad' the estimate. This isn't always a big problem, but it becomes a big problem when what we thought was an overestimate really ends up being an underestimate. The minute this becomes obvious to management and developers is usually when it's too late. McConnel describes the time consuming activities that 'snowball' as a result, forcing the task over budget and / or past deadline such as re-estimation, more meetings in an attempt to re-group, and worst of all - fixing "quick and dirty" code.

The best estimate is one that's 100% accurate, but that almost never happens. As a result decision makers are likely subconsciously adjusting our estimates downward based on the estimation trends I just discussed. So where does that leave the estimators? Is it ok to consistently give over-estimates, even when a more accurate estimate is available?

Just some food for thought...

What's Pinyination?

Pinyination - it took me awhile to come up with this, but after a lot of thought, it seems to make perfect sense. It's formed from two words - 'Pinyin' and 'Nation'. Pinyin is a somewhat phonetic interpretation of Chinese language characters, and it used to help people learn how to speak Chinese. It serves as a sort of 'middleware'- bridging two language concepts that don't even come close to mapping. We're all familiar with the word 'nation', but what we don't always realize is that nations don't always have to exist (ie: they can be made up! See http://en.wikipedia.org/wiki/Nation). Put these two concepts together, and maybe you can follow what I'm getting at. Simply put, pinyination is my attempt to identify concepts (primarily technical, but not always!) and make them understandable - to a nation of knowledge seekers and sharers. And it sounds like opinion and imagination mashed together - that wasn't intentional, but it's meaningful.

Welcome

Welcome to my blog! After attending a technical conference in Tennessee this month, I have decided to create a blog to share my thoughts, struggles, and discoveries as I start my career in consulting / software development. Aside from professional growth and contributing to the technical community, I also want my blog to offer a peek into my other interests as well. Although technically centered, I want to share my experiences outside of my profession as well.