An early attempt at being funny.

As this is a holiday week for me, I think I will take a break from my latest work in progress, Mastering Microservices In 673 Steps, and talk a little about software project estimation. Of course this is a venerable and much discussed topic. In fact, I‘ve actually found an article on it that was published before the original ship date for Duke Nukem Forever. Yes, that long ago.

I should say that I'm completely unqualified to have any opinions on software project estimation. I have spent several decades of my career building software systems. Writing software is the very simple process of selecting one of the infinite number of possible programs that will satisfy the customer‘s requirements from the vastly more infinite array of programs that won‘t. Once selected, you need to extrude the code out of your brain, down through your arms, and out onto your keyboard. Imagine squeezing that last bit of toothpaste out, from the point of view of the tube. Sadly, compared to the simple and relatively easy process of actually writing code, software project estimation is something of a painful black art.

Consider all the factors involved in estimation. First you have your customer. You do have a customer, right? I'm a big fan of agile techniques, and one of our principles is that you have an on-site customer, a knowledgeable and well informed individual who is constantly right there with the developers, providing requirements guidance and helping set priorities. I‘d introduce you to my on-site customer, but he seems to be having lunch with Jimmy Hoffa at the moment.

Then there is the deployment environment. Rare is the project that starts with a clean sheet. You will usually need to build your code on top of an existing infrastructure. Most of the time this infrastructure is made of up technology selected by an exhaustive brochure based evaluation of nearly two alternatives.

Hardware can also be a problem. I think that management sometimes thinks that developers just want bigger and better machines so that our WarCraft frame rates will be higher. Not only is that unfair, but I just can‘t get my tech lead to close the door to his office when he is storming the Temple of Atal‘Hakkar. It‘s a very noisy process.

Is there any hope? I think so. Over the years I have found a nearly foolproof technique for software project estimation. By foolproof, I mean that it doesn‘t always fail. Mostly it doesn't fail. Well it worked once. Nearly once. Anyway, my software project estimation technique is to simply find the most knowledgeable developer and ask her, "How long is this going to take?" Get her answer and adjust it slightly for the well know developer optimism effect. This adjustment is very simple: take the developer estimate, double it and move to the next higher unit of time. If the developer thinks it will take three hours then the adjusted estimate is six days. If the raw estimate is a couple of days then think four weeks. Five weeks gives you ten months.

The software industry has only been around for thirty years or so. We are making great progress, but I think our best times are ahead of us still. We do have a problem estimating software projects, but I think we can beat it in the next couple of years. Four decades, tops.

– Russ