How Do You Accurately Estimate Programming Time? 483
itwbennett writes "It can take a fairly stable team of programmers as long as six months to get to a point where they're estimating programming time fairly close to actuals, says Suvro Upadhyaya, a Senior Software Engineer at Oracle. Accurately estimating programming time is a process of defining limitations, he says. The programmers' experience, domain knowledge, and speed vs. quality all come into play, and it is highly dependent upon the culture of the team/organization. Upadhyaya uses Scrum to estimate programming time. How do you do it?"
Specs (Score:2, Insightful)
For me it really depends on how accurately they spec it out. If it is a general idea I can be an order of magnitude off easily. If it is a very accurate spec and needs little change throughout then I tend to be pretty accurate.
My Ass (Score:5, Insightful)
I pull numbers out of my ass.
If I am ahead of schedule, rock on
If I am directly on schedule, rock on
If I am behind schedule, creatively blame something that is out of my control to begin with, rock on
W.A.G. (Score:5, Insightful)
After 40+ years of programming it's still a Wild Assed Guess.
You're never given enough time to prepare your estimate, marketing has already
determined the delivery date, and management doesn't know what it is you're
supposed to create anyway.,
Re:It's Easy (Score:5, Insightful)
I wish I had mod points for this - it's the most realistic answer yet!
Quid pro quo (Score:5, Insightful)
The programmers' experience, domain knowledge, and speed vs. quality all come into play, and it is highly dependent upon the culture of the team/organization.
My time estimates will be as accurate as your specs. You stick to the specs, I'll stick to the estimate.
Method changes based on scope (Score:3, Insightful)
Are we estimating a tweak to an existing feature? Or the creation of an architecture for a high-volume real time production system?
That matters. Methods that are cost-effective for one are worthless for the other.
And there are other concerns...like....how much are we allowed to spend on the estimate itself? That will put limits on the accuracy and precision (the difference between which is critical to understand in any methodology), as well as further determine what kind of estimation methodology can be used.
In order to answer the question put forth in the summary, I will first need more relevant details.
My experience working both with huge and tiny projects has taught me this:
One size does not fit all.
Re:Simply, no software required. (Score:4, Insightful)
I take the amount of time I think it will take, double it and move it up a time unit.
So, if I think it will take two days, I estimate 4 weeks. If I think it will take a week, I estimate two months and so on.
Exactly my method too. I assume we both stole it from the same place, but I can't remember where. I am also ashamed that it is often right.
Which either means I'm lousy at estimating or brilliant. Or maybe just lousy at implementation. Or maybe nothing at all.
But it doesn't matter, of course, since the boss will ask "Are you sure?" And we all know that that means "try to come up with an estimate that fits my predetermined schedule." So you either cut features/quality by plan or by fact. Usually by fact, since no one wants to give up anything. So you give up whatever doesn't happen to be done (or give up your release date -- which is also a feature of a sort).
Deadlines are useful, though, in avoiding a DNF type situation.
Make Estimate, Track Overrun (Score:3, Insightful)
I make the initial best-guess estimates based on past projects and past developer performance. I track the initial estimate, and then I track all effort spent as it is logged. I.e. each checkin gets an "effort spent" number. I then track "actual vs. estimate" and come up with a total amount of overrun so far. I take that overrun, get a percentage (e.g. "over by 15%") and then add that back to the total estimate.
So, if the total estimate is 100 man hours, and we are currently over by 15%, I then say it will actually take us 115 hours total to finish the project.
This is based on the sage wisdom of Mythical Man Month: if you first estimate is off, so are all your estimates, usually by the same amount. As depressing as that might initially sound, it's actually accurate and it gives you a great tool for getting a real estimate once the project is underway.
So I mark my first estimates as "estimates" and then I consider the adjusted estimate once we are 2-4 weeks in to be more accurate. It has usually put us one to two weeks within the actual delivery date--which based on my experience with software development over the past 15 years is really good estimating :-) The norm on the projects I was a developer on was that overrun was closer to 90-100%. My last project I managed was 25% with new developers--I considered that a victory :-)
Re:W.A.G. (Score:1, Insightful)
Pretty much. Even when you're coding to a completely laid out specification, the time it takes to understand the specification and determine how many lines of code you'll need to write to meet each point of that specification is basically equal to the time it takes to code the specification less a factor based on your typing speed.
You could guess on a (# of bullets x avg. time per bullet) basis, but then you run into specifications like the one I'm dealing with where I've got
I.3.ii.A) Alerts indicating that data was not saved due to user error shall be red text on a white background.
and
IV.4.i.B) All data entered into any field in the software shall be retained, even if "superseded" with new data or "removed" by the user, until such time that an administrative user reviews the retained data and decides to "purge" the data from the system.
One of those is one line of code and will take about 30 seconds. The other... well, it's a good thing we read the entire spec before we began.
Exact approximation. (Score:3, Insightful)
Precise guess.
Accurate estimate.
In just one word: oxymoron.
Re:Chop features. (Score:2, Insightful)
Re:Chop features. (Score:5, Insightful)
Exactly. Ship date is a feature. It will have lower priority than some features, and higher priority than some other features.
I've never seen a team that could estimate, months in advance, when a particular feature set would ship.
I've been part of great teams that regularly review progress and have the power to adjust priorities.
Re:It's Easy (Score:2, Insightful)
Estimation is used to determine how many subtasks/features that can be done within the given time so that you can scope out features that won't make from the very beginning.
^C
Re:Uhh, Scrum is not an estimation method (Score:3, Insightful)
Do you realize that you just explained why scrum is a great estimation method? I'm gonna have to try that!
Re:Programming time? (Score:2, Insightful)
Re:Chop features. (Score:3, Insightful)
Re:Uhh, Scrum is not an estimation method (Score:4, Insightful)
In reality, by the end of the project you are creating new backlogs as fast/faster than fulfilling them. There's always code that needs to be redone, newly found bugs to fix, performance testing that needs to be done, etc. You can't "create and agree" on performance, debugging etc backlogs ahead of time.
Re:Simply, no software required. (Score:4, Insightful)
We do it backwards. The boss gives us the timeframe and we make the specs to match it.
Re:Chop features. (Score:4, Insightful)
Shipdate was the feature dropped in Duke Nukem Forever.. So it ships with all features..
Re:Chop features. (Score:3, Insightful)
The trouble is one of the biggest impact items - ie. the customers or vendors - will almost never be the same project to project. Other peoples experiences may differ but I always find that the people involved usually are the biggest factor determining if a project meets deadlines or not and you have no idea what they will be like until the project begins. Even the same person may perform differently project to project, on the first they may be a dedicated resource, on the next the project is one of a dozen they are working on simultaneously so can only devote a fraction of the time and effort of the original. I have had projects that in reality should have taken a few hours take a couple of weeks while other highly complex projects lasting several months go off without a hitch and come in early, all due to the different people.