There is a popular notion out there that estimating software projects is not possible with any level of confidence. This is misconception is popular for several reasons - all of which are due to Dilbert-style management. Estimates are misused everywhere. They are misused on IT shops, they are misused at NASA. Get over it, that's no reason not to learn how to do good estimates. Those are symptoms not the root cause of poor estimating.
First some assumptions
- You're an experienced developer in a specific domain. You're not a newbie, the ink is dry on your diploma. You have worked in this domain enough to know where the show stoppers are. You've learned about these the hard way, by encountering them first hand and experiencing the sting of defeat.
- You work in a domain you are familiar with. You haven't been asked to write code for a domain you've never even heard of. For example, you're not being asked to develop the descent control loop for the Mars Science Laboratory using your vast experience and skills in writing web-based e-commerce apps for a retailer.
- You have some sense of probability and statistics. Enough to know about the terms confidence and error band. You know enough to know that without a measure of confidence and the error on that confidence all single-point estimates are bogus. Don't work for anyone who doesn't understand this. Find a better job or a better customer.
Some Background Before We Start
These are assumed to be in place and won't count against the stopwatch I'm going to use to time you.
- You've been asked to estimate the duration of your singular effort to produce a feature in a software system.
- You understand the concept of this feature. It's not a complete mystery to you. You're experienced in the domain where this feature lives. You've got some notion of what the customer is asking for. You're not completely in the dark.
- You've worked long enough in this domain to know what is reasonable for a duration and a cost. You'd recognize some completely SWAG (scientific wild ass guess) if you saw it.
OK, Let's Start
With your knowledge and experience in the domain and a reasonable understanding of what the customer wants (no units of measure for reasonable by the way, sorry), let's ask some questions. I have no pre-defined expectation of the duration. That is I have no anchor to start. If I did and didn't have a credible estimate I'd be a Dilbert manager - and I'm not.
So let's have a dialog...
- Me - now that you know a little bit about my needed feature, can you develop this in less than 6 months?
- You - of course, I can, I'm not a complete moron.
- Me - good, I knew I was right to hire you. How about developing this feature in a week?
- You - are you out of your mind? I'd have to be a complete moron to sign up for that.
- Me - good, still confirms I hired the right person for the job. How about getting it done in 4 months?
- You - well that still seems like too long, but I guess it'll be more than enough time if we run into problems or it turns out you don't really know what you want and change your mind.
- Me - thanks for the confidence in my ability. How about 6 weeks for this puppy?
- You - aw come on, now you're making me cranky. I don't know anyone except someone who has done this already, that can do it in 6 weeks. That's a real stretch for me. A real risk of failure and I don't want that. You hired me to be successful, and now you're setting me up for failure.
- Me - good, just checking. How about 2½ months - about 10 weeks?
- You - yea that still sounds pretty easy, with some margin. I'll go for that.
- Me - Nice, I like the way you think. How about 7 weeks?
- You - boy you're a pushy one aren't you. That's a stretch, but I've got some sense of what you want. It's possible, but I can't really commit to being done in that time, it'll be risky but I'll try.
- Me - good, let's go with 8½ weeks for now, and we'll update the estimate after a few weeks of you actually producing the output I can look at.
When I point my voice reader at that discussion it takes about 90 seconds to read with all the banter back and forth. So in 90 seconds, I can get a number - the duration for a single person's effort with a 85% confidence on the high end - that is 85% confidence in the commitment since there was a high probability in doing in on or before 10 weeks. And approximately at 85% confidence of showing up before the commitment date. That's a 15% high and 15% low estimate with absolutely no code being written, no quick exploration of the problem, nothing, nada, just 7 questions. You get within that confidence in 90 seconds you're golden.
This method is a Binary Search. You remember that in your Freshman Algorithms class. A fancier version is Wide Band Delphi - but simple and simple-minded Binary Search with upper and lower bounds will get you what you want.
So What's The Point?
When you hear you can't forecast the cost and schedule of software development work, you should Call BS. Of course, you can, it's done every single day. You may not want to for whatever perverse reason. But it's certainly possible.
And here's the bottom line - if you work somewhere writing software for money, it's usually someone else's money. That someone else is going to want to have confidence that you are actually spending that money producing something of value in exchange. Not just working until the money runs out. This means, of course, small chunks of deliverables, verified to be acceptable by those with the money. That's just good management everywhere. Everywhere from the web-app to flying to Mars - it's good management to deliver incrementally and iteratively evolve to the solution - so you can stop using the red herring of waterfall. It's forbidden in the Defense Federal Acquisition Regulation Supplement (DFARS).
So for any project for any size, first ask do you have any experience in this domain? No, you're not going to be able to do much around estimating. When we get the project going, a senior person will guide you on what to do to add value. But if you have experience, apply the steps above.
And in 90 seconds or so we can have an exchange of ideas to arrive at a mutual understanding of time and effort. In this case, the cost is simple. Labor rate x time = cost. But this works for cost too. This works because this is how the Basis of Estimates are built for multi-billion dollar programs we work on. Grander scale, much more complex discussion, much more sophisticated risk, and technical assessments, using Reference Class Forecasting Monte Carlo Simulation models. But it's the same principle.
