Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Do You Accurately Estimate Programming Time?

Soulskill posted more than 4 years ago | from the step-one-invent-time-travel dept.

Programming 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?"

Sorry! There are no comments related to the filter you selected.

Chop features. (2, Interesting)

tjstork (137384) | more than 4 years ago | (#31075050)

Estimating accurately isn't so much of an art of estimating accurately, as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it. The deal is, you have to be able to get a screen or database up and running ok in some x number of hours, and prioritize, to fit that estimate. Once you start doing that, then you can adjust your estimates to allow for more features or yes.

Method changes based on scope (3, Insightful)

Anonymous Coward | more than 4 years ago | (#31075376)

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:Method changes based on scope (1)

tjstork (137384) | more than 4 years ago | (#31075732)

One size does not fit all.

Very true. And, for a business oriented website, it may seem foolish to blow 40 - 80 hours on getting the look of a page right. But, if you are making a more media oriented site, its probably nowhere near enough.

Re:Chop features. (1)

Rob the Bold (788862) | more than 4 years ago | (#31075610)

The deal is, you have to be able to get a screen or database up and running ok in some x number of hours, and prioritize, to fit that estimate. Once you start doing that, then you can adjust your estimates to allow for more features or yes.

Unfortunately, features usually get cut by chance rather than by plan since no one wants to give up on anything, including the deadline. As you suggest, it would be be better to do it in a conscious way, but that seems way too rare in practice.

Re:Chop features. (2, Insightful)

oldspewey (1303305) | more than 4 years ago | (#31075718)

It's the Project/Program Manager's job to manage scope expectations in such a way that features do indeed get cut by plan rather than chance. Having said that, very, very few PMs I've worked with are actually good at this aspect of their jobs. Most of them prefer to avoid conflict and maintain a sort of comfortable fiction with the client until things reach a point where that fiction is simply unmaintainable.

Re:Chop features. (4, Funny)

Hognoxious (631665) | more than 4 years ago | (#31075866)

features usually get cut by chance rather than by plan since no one wants to give up on anything, including the deadline.

Have you ever asked which feature has the highest priority, and received the answer, "all of them"?

The type of twits who give that answer always think they're combining the wit of Oscar Wilde, the insight of Confucius and the cock of John Holmes.

Re:Chop features. (0, Funny)

Anonymous Coward | more than 4 years ago | (#31075886)

You can create software on time, have good quality, or cheaply. Pick one.

Function Point Analysis and Man Hours (1)

GameGod0 (680382) | more than 4 years ago | (#31075054)

Re:Function Point Analysis and Man Hours (0)

Anonymous Coward | more than 4 years ago | (#31075476)

Ah, good ol' function point analysis. I thought most intelligent people realized that it was a whole load of bullshit right around 1983 or so.

Re:Function Point Analysis and Man Hours (1)

Rob the Bold (788862) | more than 4 years ago | (#31075700)

Ah, good ol' function point analysis. I thought most intelligent people realized that it was a whole load of bullshit right around 1983 or so.

Doesn't mean it's not useful -- just not useful for estimating actual time. You create an estimate, you've got data to back it up. Sure it's just as much a WAG as anything, but it's such a Scientific WAG, what with all the numbers and calculations. Gets management off your back until you miss enough deadlines, checkpoints, tollgates, or whatever they want to call them.

Theory is nice, but.... (0)

Anonymous Coward | more than 4 years ago | (#31075510)

Here's the problem with the above, it assumes the functionality has no unknowns. Meaning, once you spec it out, it just a matter of design and code and everything goes relatively smoothly. I just spent a few days trying to get an image module to work in C# and Silverlight. The code worked fine, but no image. Finally giving up with beating my head against the wall and reading MS documentation, I posted a question on the SL forums. Silverlight doesn't support GIF - that was the image format I was using. Apparently, MS thinks that GIF is old fashioned and going away. Translation? All the examples and techniques were written for SL2, they wouldn't even compile in SL3 let alone work.

Anyway, how do you plan for that? You choose a technology, say Java Beans or JBOSS and the problem you get isn't easily solved with the platform or may not even be supported. You're on your own - gotta roll your own. And even then, can you do it in Java?

How do you plan for that? And it seams as though, every project is like that - there's always something that pops up that's a big question mark and the solution could happen in a morning or never.

Sure, a typical database application: data in, data update, data delete, etc.. could work very well with that planning technique, but some new product? Something that hasn't been done before or has been done very infrequently?

Re:Function Point Analysis and Man Hours (0)

Anonymous Coward | more than 4 years ago | (#31075870)

So my team has just spent about 6 man years making one very complicated system into a an HA pair of very complicated systems. From a user functional analysis that's one extra function with one big bang. There is no way that we could have gotten from that to 6 man years.

Scrum all the way baby.

Programming time? (1)

Spyware23 (1260322) | more than 4 years ago | (#31075062)

"when it's done"

Re:Programming time? (1)

creimer (824291) | more than 4 years ago | (#31075310)

Still waiting for Duke Nukem Forever?

The formula (0)

Anonymous Coward | more than 4 years ago | (#31075068)

6 x wild_guess + 2 weeks

Re:The formula (1)

SpryGuy (206254) | more than 4 years ago | (#31075494)

Actually I always use this:

    X = Initial Estimate

    What you tell management = Double X and raise the units by one.

So if the initial estimate is 2 hours, then you tell management 4 days. If the intial estimate is 3 days, then you tell management 6 weeks. You get the picture.

A better formula (3, Funny)

CorporateSuit (1319461) | more than 4 years ago | (#31075880)

Find out how much time you can spend on the project before you'd get fired for laziness, then subtract a day.

Simply, no software required. (5, Funny)

loftwyr (36717) | more than 4 years ago | (#31075070)

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.

Re:Simply, no software required. (4, Informative)

WrongMonkey (1027334) | more than 4 years ago | (#31075160)

In other words: the Scotty Principle.

Re:Simply, no software required. (1)

loftwyr (36717) | more than 4 years ago | (#31075196)

Nah, by his own words, he just multiplied the actual time by 4.

Back-fill after you are finished (1)

xzvf (924443) | more than 4 years ago | (#31075720)

Complete the programming job, then fill in the calendar when you are done.

Re:Simply, no software required. (3, Insightful)

Rob the Bold (788862) | more than 4 years ago | (#31075418)

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.

Re:Simply, no software required. (0)

Anonymous Coward | more than 4 years ago | (#31075486)

1 month becomes 2 years?

Re:Simply, no software required. (1)

brainboyz (114458) | more than 4 years ago | (#31075618)

2 quarters.

minutes
days
weeks
months
quarters
years

Re:Simply, no software required. (1)

brainboyz (114458) | more than 4 years ago | (#31075636)

and, of course, I forgot hours in there.

Re:Simply, no software required. (1)

HoboCop (987492) | more than 4 years ago | (#31075776)

fortnight?

Re:Simply, no software required. (0)

Anonymous Coward | more than 4 years ago | (#31075796)

8 hours -> 16 days
1 day -> 2 weeks
Do you go with the high or the low estimate here? Of course this assumes an 8 hour work day, but you would have to assume a 5 hour day for the two values to equate.

Re:Simply, no software required. (3, Interesting)

Chapter80 (926879) | more than 4 years ago | (#31075702)

The method I was taught in school, back in the days when Arthur Andersen existed, and prior to Andersen Consulting or AssVenture (or whatever they're called now), the method that was taught to me was credited to them, and looked like this:

Estimate how long it will take, if everything goes right. Call it T1.
Estimate the expected time it will take, knowing how some things usually go wrong. Call it T2.
Estimate the worst possible case, if everything goes wrong, and there are lots of unforeseen issues - you are 99% sure you can get it done within this amount of time. Call it T3.

The Weighted average estimate is (T1+(4*T2) + T3)/6

This yields some very odd T values, but often works out to be a reasonable estimate. The developers may tell me "If all goes well, it'll take 2 days. I expect it to be 4 days. But worst case, it might be 40 days." And you end up with a 9.6 day estimate. (which is SIGNIFICANTLY different than the "I expect it to be 4 days".)

----

The part I learned from working for a major computer manufacturer was this:

Take whatever estimate the developers tells you, and tell the client to expect it in double that time (from today). If the lab tells you they'll have a fix by tomorrow, tell the client it'll be there the next day. If the lab tells you it'll be ready in three months, tell the customer 6 months. That way, as time goes by, the estimates become more real, and the variation from the estimate becomes more refined. And it accounts for the unavoidable time between when the lab releases the work, and when it gets installed at the customer's site.

If, in January, I was told by the developers that it'd be ready in 2 months, I will tell the customer to expect it in 4 months (May). If in February, I haven't gotten a revised time-frame, then we still expect it in four months (June).

Manage expectations, and don't let the customer down (particularly when things are outside my control).

Re:Simply, no software required. (4, Funny)

computational super (740265) | more than 4 years ago | (#31075816)

Hofstadter's law: It always takes longer than you expect, even after accounting for Hofstadter's law.

Specs (2, Insightful)

TheTick21 (143167) | more than 4 years ago | (#31075082)

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.

Re:Specs (1)

FooAtWFU (699187) | more than 4 years ago | (#31075276)

I don't work with detailed specs, but I do work with estimating a lot of small tasks (on the order of days at most) instead of estimating one big thing. I think that's sort of the Scrumm-my angle they're talking about in TFS, though.

Re:Specs (1)

Lumpy (12016) | more than 4 years ago | (#31075396)

You nailed it.

If the Scope of work document is inaccurate then the estimate on time will be inaccurate.

Give me a real Scope of work, I'll give you a real estimate of time. If someone would clamp battery terminals to the Executives nipples and not stop shocking them until they get it through their heads, we all would not have to guess.

The WAG Methodology (0)

Anonymous Coward | more than 4 years ago | (#31075086)

... aka "Wild Ass Guess." :-)

Blindfold and dartboard (1)

91degrees (207121) | more than 4 years ago | (#31075102)

Write down all the possible times on bits of paper. Put on blindfold. Throw darts. There's your estimate. I'm consistently getting more accurate times than any other method.

Why does a dog lick his balls? (0, Offtopic)

Third Position (1725934) | more than 4 years ago | (#31075104)

How Do You Accurately Estimate Programming Time?

I'm sure there's a great punch line that goes here, but I just can't think of one just now.

Opening the floor for suggestions!

Re:Why does a dog lick his balls? (1)

Rockoon (1252108) | more than 4 years ago | (#31075146)

I can't because I'm using floating point.

Re:Why does a dog lick his balls? (1)

Opportunist (166417) | more than 4 years ago | (#31075266)

"By implementing it and then telling them how long it has taken".

It's a bit like writing the specs AFTER coding the tool. Makes it heaps easier to deliver everything according to spec.

Re:Why does a dog lick his balls? (0)

Anonymous Coward | more than 4 years ago | (#31075536)

"By implementing it and then telling them how long it has taken".

That approach came in very handy when I was designing my time-machine. Or will have been coming in very handy. Something like that.

There's a hard way and an easy way. (0)

Anonymous Coward | more than 4 years ago | (#31075118)

How do you do it?"

Equivocally. Like everyone else

This is what I usually do. (4, Interesting)

tool462 (677306) | more than 4 years ago | (#31075122)

I'll throw together a script that takes in all of the project parameters as input, then based on the number of people in the team, past performance, scheduling deadlines and intermediate deliverables, comes up with an estimate for final delivery.

Then I throw out that number completely, and just multiply the time it took me to develop that script by five. This method has proven disturbingly accurate.

Re:This is what I usually do. (1)

DoofusOfDeath (636671) | more than 4 years ago | (#31075294)

Then I throw out that number completely, and just multiply the time it took me to develop that script by five. This method has proven disturbingly accurate.

So you spend 16% of the project time developing estimates?

Re:This is what I usually do. (4, Funny)

tool462 (677306) | more than 4 years ago | (#31075330)

I figure it boosts my efficiency by getting all my wasted time in up front.

Re:This is what I usually do. (2, Funny)

Anonymous Coward | more than 4 years ago | (#31075436)

Then I throw out that number completely, and just multiply the time it took me to develop that script by five. This method has proven disturbingly accurate.

So you spend 16% of the project time developing estimates?

No kidding.

How do you get it so low? Was your project manager sick?

Heh (0)

jav1231 (539129) | more than 4 years ago | (#31075128)

You have to admit, there's some irony in "estimating" time with regards to computer programming.

Yes, that's supposed to be funny. :(

How do you do it? (1)

John Hasler (414242) | more than 4 years ago | (#31075134)

/dev/random works for me.

My Ass (4, Insightful)

i_ate_god (899684) | more than 4 years ago | (#31075144)

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

Re:My Ass (1)

MrCawfee (13910) | more than 4 years ago | (#31075318)

This happens to be my strategy too. No matter how long i say though, they expect it to be completed 15 minutes after they tell me about the problem... even if it is a 6 month project....

Re:My Ass (1)

NeoSkandranon (515696) | more than 4 years ago | (#31075662)

Even if management DOES understand, the sales guy has more clout than your manager because THIS IS AN IMPORTANT CLIENT GUYS. /bitter

Re:My Ass (1)

coinreturn (617535) | more than 4 years ago | (#31075838)

We have a name for this - PIDOOMA, which stands for Pulled It Directly Out Of My Ass. If the numbers are particularly rough, we will sometimes call it unwashed PIDOOMA to emphasize that we have not analyzed the numbers at all.

joel on software (0)

Anonymous Coward | more than 4 years ago | (#31075150)

I just make a wild guess and multiply by 2. Joel Sposky had a different take on time management:

http://www.joelonsoftware.com/items/2007/10/26.html [joelonsoftware.com]

Re:joel on software (1)

rrhal (88665) | more than 4 years ago | (#31075314)

That's what I do - make an estimate that you think gives you lots of time; then double it. It's still a WAG

W.A.G. (5, Insightful)

ipb (569735) | more than 4 years ago | (#31075170)

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:W.A.G. (1)

characterZer0 (138196) | more than 4 years ago | (#31075464)

And hey want an estimate before writing a specification, and change the specification without allowing changes to the estimate.

Re:W.A.G. (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31075580)

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.

Stop estimating a single number (0)

Anonymous Coward | more than 4 years ago | (#31075186)

Nobody can ever give you a usable number. No matter how often you ask them. Instead, ask them for 5%, 50% and 95% numbers. These numbers indicate both the expected completion date, the amount of work they estimate and their feeling of worst-case, or uncertainty. When the three are far apart, that's a hint to you that it's not sufficiently clear & they need more data. When they're very close together or the developer refuses to give them, there's probably some pressure on him that would disadvantage him if he did - for example, knowing your response to his actual 95% number.

The George Carlin Principle... (3, Informative)

TheDarkMinstrel (1671156) | more than 4 years ago | (#31075204)

Show me a staff that consistently delivers products on time and one of the following will always be true:

1) One or more of your highest performers works extensive amounts of overtime (and is likely to burnout)
2) Project times are consistently overestimated.

It's a variation of the George Carlin Principle... People will adapt to fill the space, one way or the other.

.NET (1)

cosm (1072588) | more than 4 years ago | (#31075220)

( [Average copypasta time] x [Desired Lines of Code] / [Averages Lines Per Chunk] ) x K K = Constant of Desired Inneficiency

It's Easy (5, Funny)

BabyDuckHat (1503839) | more than 4 years ago | (#31075234)

I just ask my manager how long he's already told the client it's going to take.

Re:It's Easy (5, Insightful)

VoxMagis (1036530) | more than 4 years ago | (#31075282)

I wish I had mod points for this - it's the most realistic answer yet!

Re:It's Easy (1)

GNUALMAFUERTE (697061) | more than 4 years ago | (#31075668)

And then just don't sleep for as many days as necessary to deliver, work on weekends, and deliver ontime, without testing, knowing that the binaries you are delivering where compiled the night before the delivery date at 5 A.M.

Yes, it's my way ...

Hofstadter's Law (1, Informative)

Anonymous Coward | more than 4 years ago | (#31075258)

http://en.wikipedia.org/wiki/Hofstadter%27s_law

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Why bother? (1)

lwriemen (763666) | more than 4 years ago | (#31075292)

... if management is just going to come back and say, "Well, I told the customer it would be done by "

Seriously though, you might want to read, Software Engineering Economics by Barry Boehm. Some of the examples of work products might be outdated, but the concepts are still valid and useful.

Does it matter? (1)

Opportunist (166417) | more than 4 years ago | (#31075300)

Why should I bother to figure out how long it will take to implement it? Marketing has certainly already set a delivery date, so that burden is taken off your shoulders.

Well, I *used* to use the entrails of goats... (4, Funny)

gestalt_n_pepper (991155) | more than 4 years ago | (#31075334)

But the folks who used the table in the lunchroom complained, so we now use the far more sophisticated system of tea leaf reading. This upsets nobody but the tea drinkers as we frequently need to user their cups before they're done, but then tea drinkers are wussies anyway.

Re:Well, I *used* to use the entrails of goats... (1)

GNUALMAFUERTE (697061) | more than 4 years ago | (#31075858)

>>but then tea drinkers are wussies anyway.

Agreed. Never trust a programmer that doesn't drink coffee.

Quid pro quo (5, Insightful)

HangingChad (677530) | more than 4 years ago | (#31075338)

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.

Cart before horse. (1)

PeanutButterBreath (1224570) | more than 4 years ago | (#31075342)

Typically, the solution is much more malleable than time or budget. Determine the baseline requirements. Then determine the resources available (time and money). The project will likely fill the latter two. Success should be measured against adherence to the requirements, not time or money saved.

Fixed Price or Cost +? (0)

Anonymous Coward | more than 4 years ago | (#31075344)

For fixed price, WAG*3
For Cost+, WAG*2

Beers as a temporal unit (1)

mlts (1038732) | more than 4 years ago | (#31075354)

I do know what not to do. When someone estimates a programming job in number of beers, I get worried. If someone says that a security patch to an existing application is a one beer job, then I hope for the best, and that regression testing and QA catch anything new that cropped in.

Change the units and multiply by 2 (0)

Anonymous Coward | more than 4 years ago | (#31075358)

If you think something will take an hour, change the unit to a day and multiply by 2
So
1hr=2days
1 week=2 months
and so on

Easy (1)

Joucifer (1718678) | more than 4 years ago | (#31075364)

Take my initial guess and either multiply by 2 and add a 0.

Re:Easy (1)

Joucifer (1718678) | more than 4 years ago | (#31075400)

Take my initial guess and either multiply by 2 and add a 0.

or. not and.

Estimate, Get Feedback, Repeat... (1)

fortapocalypse (1231686) | more than 4 years ago | (#31075368)

It is just like anything else. You practice, you get feedback, and you keep trying. That method should apply to getting better at both high-level and task-level estimation for any task (not just development). The methods that help you produce better estimates will develop based on experience and feedback. Historical reporting and adequate (but quick) data collection are key. While there are tools out there to help you determine where people are spending time, nothing substitutes for people estimating their work or the work of their team. Unfortunately, estimation is not valued in all environments, and can turn some developers off.

Multiply by 3 or 8 (1)

khendron (225184) | more than 4 years ago | (#31075378)

I really don't know why this is as accurate as it always turns out to be, but it really works.

I look at the specs of what needs to get done, and I do a quick back of the envelope estimates as to how long each feature will take (e.g., feature A: 5 days, feature B: 2 weeks, etc). Then I multiply each estimate by 3 and add it all up. If some sort of hardware interfacing is required, I multiply the estimate by 8.

My supervisor for my Masters degree taught me this trick, when I was programming a sensor control system for a wind tunnel. I didn't believe him at first, but he turned out to be right.

Miracle Worker! (1)

mackil (668039) | more than 4 years ago | (#31075422)

Times every quote by 10! How else will they think you're a miracle worker laddie?

Multiply by Three (1)

4pins (858270) | more than 4 years ago | (#31075434)

1. Break the program into it's component parts.
2. For each component ask, "How long should this take?"
3. Multiply that number by three and record it.
4. Add up all the numbers.

I have used this method successfully for projects lasting only a few hours up to six months.

Uhh, Scrum is not an estimation method (5, Interesting)

pclminion (145572) | more than 4 years ago | (#31075438)

Scrum is a way of chunking development into well-defined portions. The idea of using Scrum to estimate time just doesn't make sense. Everything in Scrum takes the same amount of time. Two weeks. (Or one week, or whatever your sprint length is.) The difference is that long projects are implemented over multiple sprints, since obviously, not everything can be done in two weeks. So the estimate is not of how long it will take, but how many backlog items will be required in order to reach some known endpoint. Once the backlogs have been created and agreed upon by the team, estimating the necessary time becomes a matter of multiplication: 12 backlogs * 2 weeks = 24 weeks to finish this product.

This makes you shift your thinking from "how long will it take to do all these things" to "how can I break this product development into chunks which each fit into a two-week period?" That's much easier than making wild-ass guesses about the time it takes to do something.

Make Estimate, Track Overrun (2, Insightful)

Kostya (1146) | more than 4 years ago | (#31075458)

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 :-)

My usual approach (1)

jockeys (753885) | more than 4 years ago | (#31075470)

is to sit down and figure out how long it should take under ideal circumstances (no scope creep, no major fuckups, no outside holdups) and triple it.

That sounds awful, but it's almost always pretty close. Something always goes wrong, there is always some amount of re-work and there is always some scope creep.

Depends (1)

DoofusOfDeath (636671) | more than 4 years ago | (#31075472)

Are we talking before or after the contract is signed?

The Mythical Man Month may provide some insight (1)

ma11achy (150206) | more than 4 years ago | (#31075484)

I would advise reading "The Mythical Man Month" by Frederick P. Brooks. It is considered "The Bible" of the human elements of Software Engineering by many. By "human elements" I mean to include your request for information on estimating project time.

Here is a quote from page 20 of the book based on one portion of a software engineering project:

"In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose. Many of these were on schedule until and except in system testing." (Brooks, 1995)

Citation:

Brooks, Frederick P. (1995) The Mythical Man-Month: Essays on Software Engineering: Addison-Wesley Professional, p. 20

Dilbert (0)

Anonymous Coward | more than 4 years ago | (#31075488)

Collect the relevant cartoons together and you'll have a fairly thorough treatise on the subject.

Thumbrule (1)

N8F8 (4562) | more than 4 years ago | (#31075514)

Look at past performance, adjust for scope of the job, triple it and add 30%. We programmers are always too optimistic. It's always the unpredictable 20% that takes 80% of the time.

Schedules are complex (1)

plost (1741434) | more than 4 years ago | (#31075518)

Software schedules are complex. There's a real part and there's an imaginary part.

Use the "double-up" method: (1)

bittmann (118697) | more than 4 years ago | (#31075546)

Do a best-case estimate of the time required, assuming everything goes perfectly and that there are no surprises. Next, double your estimate. And finally, switch to the next highest unit of time measure.

A quarter-hour change will take half of a day. 2 hours becomes 4 days. 3 days becomes 6 weeks. A 6-month project will take 12 quarters, or 4 years.

It's eerie how often that rule of thumb seems to accurately depict the actual calendar time required -- eerily enough that when a so-called "realistic" estimate DOESN'T approach this metric, I find it's usually worth a second look.

Thankfully, at least at my place of work, this rule of thumb seems to break down once the unit of measure hits a year...

It's all about uncertainty (1)

AardvarkCelery (600124) | more than 4 years ago | (#31075578)

Agreed. The main complicating factor is the level of uncertainty:

  • Ambiguity in the specification
  • Unfamiliar technology
  • Code design with non-obvious solutions
  • Interface constraints that must be reconciled

I list the uncertainties, make a wild guess on each one, and finally triple the result. Historically I only successfully predict about 1/3 of the problems that are going to come up.

The hard part is justifying the inflated estimate when asked, since it's based on difficulties that I haven't actually identified yet.

Exact approximation. (2, Insightful)

Nicolas MONNET (4727) | more than 4 years ago | (#31075616)

Precise guess.

Accurate estimate.

In just one word: oxymoron.

estimation (1)

God of Lemmings (455435) | more than 4 years ago | (#31075692)

I've found its only realistic to base a time estimate on how long it took to make a component (or something similar) the first time around.

Depends (1)

93 Escort Wagon (326346) | more than 4 years ago | (#31075694)

For simple projects I can usually draw upon past experience. With complex projects, if the "client" was good about thinking through what they really are asking for, estimating the time needed is normally still pretty straightforward. But most of the time the client hasn't truly thought about any specifics regarding what they think they want, and will almost certainly bring up very involved new features mid-project - so in those cases I make a wild guess and then round up.

In all instances, though, there's another significant factor. If my boss is going to be materially involved in the project, I take my initial estimate and multiply by 3.

virgin territory (1)

hey (83763) | more than 4 years ago | (#31075704)

By its nature software is always virgin territory. If it had been before then why are they asking you to do it? So its hard to estimate how long it will take because its never been done before.

Easy... (1)

ArcadeNut (85398) | more than 4 years ago | (#31075726)

I do the project first, then give them the estimate of how long it will take. For some reason, projects still take longer then estimated...

It's very easy (1)

BenSchuarmer (922752) | more than 4 years ago | (#31075742)

Just say "It will take between ${minimum_estimate} and 40 years". Chances are pretty good that this estimate will be accurate (and if it's not accurate you'll be retired by then).

Making an estimate both accurate and precise is harder.

How Do You Accurately Estimate Programming Time? (1)

weicco (645927) | more than 4 years ago | (#31075748)

I don't.

There are situations where I can take a wild guess but questioner must understand that a) it's a wild guess b) it only works in perfect world and if something goes wrong, and especially if that something is something I have no power over with, then you can safely double my bet. These situations are like if I'm asked to write some web based app for people who really don't know what they want. (Web based apps are for some reason really hard for me)

Then there are situations where I can take an educated guess. These are typically situations where I've written same kind of application before. These situations are starting to come more and more common now when I have ten years of professional programming experience behind me.

But if you keep gun to my head and demand exact estimate (can estimate even be exact?) then you could just go ahead and shoot me.

My Method... (1)

gers0667 (459800) | more than 4 years ago | (#31075750)

Think of the time it will take in an optimal environment.

Multiple by 3.

you Fail it (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#31075778)

The usual way... (1)

garg0yle (208225) | more than 4 years ago | (#31075786)

Double it, and add thirty!

You don't... (1)

karcirate (1685354) | more than 4 years ago | (#31075792)

Accuracy in estimating programming time? Last I heard, J.K Rowling hasn't written that book yet.

How long can we stretch it out? (0)

Anonymous Coward | more than 4 years ago | (#31075828)

Ask any consultant and they'll say that it takes as long as we think we can get away with.

Bill per hour (2, Interesting)

aclarke (307017) | more than 4 years ago | (#31075868)

I almost always bill per hour. Most of the time my clients give me an email or verbal idea of what they want over the phone. I try to get as many questions answered as I can without wasting time.

I then take the task and break it down into as many bite-sized subtasks as I can. This does a couple things:

1. It shows where I have unanswered questions
2. It's easier to estimate "add 3 new roles to management interface" and "add cart admin role to admin interface" than it is to estimate "make admin area more secure".

Once that's complete (for this round), I put all those line items into a spreadsheet. I then estimate the number of hours it takes in a reasonable best, and worst, case scenario. So "add cart admin rold to admin interface" might be 3-4.5 hours.

I then add all those up, and add about 33% for planning, and 33% for testing/deployment. Sometimes it can be more or less depending on my experience with the client. I then give that spreadsheet to the client and say, I'm pretty confident your price will be within this range. The areas that have high variability are the areas we need to work on nailing down further. I will bill you actual time taken, but I'll let you know if the range is nearing the top number so we can re-evaluate. That almost never happens, or I should say that when it does, it's almost always because the client has asked for more work, and they understand this.

Customers almost always appreciate this approach and find it helpful. Most of the time I only do this for the first project for a client, and then they just ask me to give them a verbal idea of how hard the project will be since they trust me.

For the very occasional fixed bid work I do, I just take the high number, pad it a bit, and double my hourly rate. I tell customers ahead of time though that they are better off hiring me hourly in almost every circumstance. I usually don't spend a lot of time on fixed bid work because, frankly, I usually don't want it.

we use scrum/invest stories (2, Interesting)

Surt (22457) | more than 4 years ago | (#31075892)

And probably more importantly than estimating accurately, we aim to estimate consistently. Then we compare actual rate of feature completion against the estimated size of remaining features. We've landed within a single sprint of estimates over a year long release with 20+ developers.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?