Of the many necessary evils of development, I suspect I like estimation the least. Providing estimates of the number of hours to complete a task, or some set of tasks, is far more art than science. There is also a considerable amount of CYA involved: it’s a far safer bet to overestimate, and complete the project sooner, than to underestimate, and find oneself in the uncomfortable position of going cap-in-hand to the Project Manager to beg more hours.
It seems to me that most of the problem of estimation lies in methodology, or more accurately, the lack thereof. Not only is estimation mostly an art, but it’s mostly an art without ground rules. Tarot reading has more basis in science than most of the estimates I’ve provided. The majority of developers don’t keep detailed statistics on how long it takes to perform a particular task: writing a table script, say: and aren’t likely to start any time soon. The best efforts of management to force us down those channels: checklists, various integrated task generators, and so on: wind up being short-circuited, under-utilized, or flat-out ignored.
To compound matters still, there are estimates, and there are estimates. There’s something called a “Rough Order of Magnitude” estimate, in which one is given a fifty-thousand foot view of a fair guess as to the likely requirements, and expected to provide a fifty-thousand foot view of a fair guess as to how many hours it’s likely to take to satisfy same. Then, when the requirements are nailed down – or at least temporarily stabilized – we generate another estimate, which we estimate to be a better guess than the previous estimate, but not by much. Finally, when the technical specifications are complete, we can look at things at the task level, and provide what ought to be a reasonably accurate estimation of the time required for development.
Except it seldom is…is it.
And why is this? Much of blame lies on the nature of development itself. It’s never – despite the best efforts of many – matured into anything like an assembly-line process, and all the frameworks in the world won’t ever make it so. Yes, there are tasks that are common to every project: tables, constraints, indexes, stored procedures: but the commonality stops there. Every project brings its own devils into the details. It took an hour to write that stored procedure, which is what I estimated, but it turned out to be a performance dog, and so I had to spend four hours tuning it to some semblance of decent execution time. How to account for that four hours? Do we just rely on the old rule of thumb that says take your best guess, then double it? That’s not much of a methodology, is it?
Ah, there’s that word again: methodology. A methodology, simply enough, is a systematic approach intended to produce consistent results. When you follow the instructions in a recipe, you’re following a methodology, and you’re assured a consistent result each time you do so. But how many of us have a methodology for producing estimates? Not many, I’d guess. I don’t think I do: I think what I have is a grab-bag of rules of thumb, previous experiences, and stab-in-the-dark guesstimates. Sounds like the inmates running the asylum, non?
So my plan is to come up with one, and to document that process in these pages. Maybe I’ll come up with something good; maybe I’ll fall back on old ways. We’ll see. Meantime, if you’ve a methodology you’d like to share, or an idea, or just a comment, feel free.