How good are your estimates
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
I've gotten very good at them because the only estimates I do are for cases in our fogbugz database where the new features and bugs are entered for our app. I find that my best estimates are the ones I give off the top of my head quickly after a quick read through of the case. The worst ones are when I stop and think about it for a long time and analyze it a lot. Proving once again that conscious thought is the main limiting factor in what our brains can accomplish.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
I've gotten very good at them because the only estimates I do are for cases in our fogbugz database where the new features and bugs are entered for our app. I find that my best estimates are the ones I give off the top of my head quickly after a quick read through of the case. The worst ones are when I stop and think about it for a long time and analyze it a lot. Proving once again that conscious thought is the main limiting factor in what our brains can accomplish.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
I use the 'Scottie' principle of time estimation - figure out how long and double it. If you come in under then you're a hero; come in over and you're a zero. Oh, and 20+ years of experience also come in quite handy...
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
Before my career started my estimates were horribly optimistic. I learned from that and fairly soon after becoming a professional developer, got and maintained a reputation for having dead-on estimates. The more experience I get, the better my estimates. One "trick" is to always be conscious of how long things take; not just projects, but individual tasks. When a new project comes up, you break it down and find comparable tasks. (This is all mental; I don't look at pieces of paper.) A twist on this is that many times my employer or client needs something done by a specific deadline. I then work in reverse and identify what can and can't be done in that time frame. I then give them choices. What's weird to me is how often management doesn't understand this or don't want to. (Incidentally, one thing that really helped was learning how to do script breakdowns in film school. Oddly enough, though, my programming experience got in the way on an educational film I did; I was too pessimistic. On the other hand, my crew, who were used to working 12 hours a day were working 8 to 9 and loved me--I think it paid off [we had one very long day and I confirmed once again that after 10 hours, productivity drops precipitously].)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Consistently bad. I create a list of high-level tasks, break them down into smaller tasks, and estimate the time needed for each based on past experience... The end sum is almost always half of the actual time needed once all is said and done... ...Of course, if i anticipate this discrepancy and double the final result, it'll still end up being wrong by about the same margin. It's like i work slower when i think i have more time...
Shog9 wrote:
...Of course, if i anticipate this discrepancy and double the final result, it'll still end up being wrong by about the same margin. It's like i work slower when i think i have more time...
In my current task, which should not take more than a week ( true estimation ), I worked for 3.5 days and got about 95% done. Then the boss mentioned when he needs it (which was in 3 weeks), and it took me 2 weeks to complete the rest 5%, which should not have taken more than a day. Of course, I'd multiple other things going, but the thing is, in my mind I said I have enough time and ended up pushing it to the backburner. :-O :-\
Yusuf May I help you?
-
Shog9 wrote:
It's like i work slower when i think i have more time.
I think it is a problem with everyone.:)
Rama Krishna Vavilala wrote:
I think it is a problem with everyone
ditto!:thumbsup:
Yusuf May I help you?
-
John C wrote:
Proving once again that conscious thought is the main limiting factor in what our brains can accomplish.
This is why i write code with an ink pen... :rolleyes:
...in the air, with a blast helmet on...
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Oh
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
Rama Krishna Vavilala wrote:
Have you ever given any estimations
Uhm.... yes
Rama Krishna Vavilala wrote:
If yes how far off were they
Always right on target
Rama Krishna Vavilala wrote:
how do you manage that
There is one and only one estimate that you should ever give, "It's done when it's done" :-)
Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy Individuality is fine, as long as we do it together - F. Burns Help humanity, join the CodeProject grid computing team here
-
So my question to you is have you read that book and how much did it improve your estimation skill? BTW I have read that book ;)
Rama Krishna Vavilala wrote:
have you read that book
Yes
Rama Krishna Vavilala wrote:
how much did it improve your estimation skill?
Quite a lot. I try out the techniques on my personal projects, and I've gotten visibly better. Haven't applied them on official work though, mostly because estimates are a joke - deadlines are usually fixed before we are asked for estimates :(
Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
Words of Marc Clifton.
Cheers, Vikram.
Current activities: Films: Philadelphia TV series: Friends, season 4 Books: Six Thinking Hats, by Edward de Bono.
Carpe Diem.
-
Shog9 wrote:
...Of course, if i anticipate this discrepancy and double the final result, it'll still end up being wrong by about the same margin. It's like i work slower when i think i have more time...
In my current task, which should not take more than a week ( true estimation ), I worked for 3.5 days and got about 95% done. Then the boss mentioned when he needs it (which was in 3 weeks), and it took me 2 weeks to complete the rest 5%, which should not have taken more than a day. Of course, I'd multiple other things going, but the thing is, in my mind I said I have enough time and ended up pushing it to the backburner. :-O :-\
Yusuf May I help you?
Yusuf wrote:
In my current task, which should not take more than a week ( true estimation ), I worked for 3.5 days and got about 95% done. Then the boss mentioned when he needs it (which was in 3 weeks), and it took me 2 weeks to complete the rest 5%, which should not have taken more than a day.
Did you bill the customer for the 13.5 days? It sounds like you did other things and it took you 2 weeks to do 1 days work. Or did it actually take you 80 hours to do 1 days work?
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
Underestimating is very common. I find I double my gut estimates and get pretty close. The fact is, it's impossible to know how long something will take, unless you've done it all before, and even then, only if you can constrain the client from asking for changes, etc. I mean, the simplest thing can suddenly be hard, and vice versa.
Christian Graus Driven to the arms of OSX by Vista. Please read this[^] if you don't like the answer I gave to your question.
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
Excellent. My estimates are usually pretty good. I always quote teh customer more than my estimate (to give some breathing room in case of unforseen incidents) All those that say they estimate and double it - why not just estimate higher in thr first place? Huh? Experience allows me to be as accurate as I am. If I am unsure about something (say some requirement I haven't used before - say drag and drop on a web page - I will do a little initial R&D first - and build in extra time for that. For very short tasks my rule of thumb is that NOTHING takes less than 1/2 day. Change the text on a button - 1/2 day. I don't deal in hours, just days, and generally estimate each minor task in whole day amounts. Again, experience counts more than anything. Oh - and knowing what you are estiomating! I've seen people (many times) be asked to estimate for a job which is so ill defined that iut coujld be anything from a one week to 6 month project. In those circumstances I refuse to be drawn into an estimate without documenting what is being estimated on - otherwise you start estimating a week, but the customer is imagining all of these extra features that you hadn't a clue about and they're always unhappy about it when you increase the estimate becasue in their head they KNEW what they wanted - they just hadn't told anyone. Finally (I do ramble, don't I) I try to double-check with others. So if I estimate a task at, say, one week, and am going to assign it to a particular developer, I will give them the task and ask them to estimate it. You're right that very often they will estimate a couple of days. I then heve the choice (depending on the person and their history) of telling them my estimate was higher, and to do their best to beat it, or telling them that they NEED to do it in two days - while keeping my original one week estimate in the project plan. If they finish in 2 days, pat on back, beers all round. If not, no efect on the project, and I can show them how to estimate more accurately next time by learning from their mistakes.
___________________________________________ .\\axxx (That's an 'M')
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
My problem is that I (and other devs on my team) keep getting thwarted by folks that persist on wanting to know the absolute most optimistic outcome. "What if that problem didn't exist? How long would it take?". If the figures are presented in terms of we expect X, but it could be as little as Y, or as much as Z then the client services team gets itself in to a mess wondering what to tell the client. How about the truth? It isn't a fixed sum game. If I knew then what I know now I'd give you a different number - That's why it is presented as a range, so that unknowns are (to an extent) accounted for.
Rama Krishna Vavilala wrote:
There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time.
I think there is a built in optimism amongs most developers, myself included. Also, developers also like to please folks and if pressed the estimates they give will tend towards unrealistic optimistic answers. In reality that strategy is just deferring the conflict until later. It then becomes more painful towards the end of the project when the deadlines that were set based on the estimates whoosh by.
Man who stand on hill with mouth open wait long time for roast duck to drop in
-
I use the 'Scottie' principle of time estimation - figure out how long and double it. If you come in under then you're a hero; come in over and you're a zero. Oh, and 20+ years of experience also come in quite handy...
digital man wrote:
I use the 'Scottie' principle of time estimation - figure out how long and double it
Incorrect. Kirk: Scotty, how soon can you get the ship ready? Scotty: 8 weeks, sir! But since we don't have 8 weeks, I'll get it done in 2. Kirk: Scotty, do you always multiply your estimates by a factor of 4? Scotty: Aye, Sir! How else could I keep my reputation as a miracle worker?
Man who stand on hill with mouth open wait long time for roast duck to drop in
-
Words of Marc Clifton.
Cheers, Vikram.
Current activities: Films: Philadelphia TV series: Friends, season 4 Books: Six Thinking Hats, by Edward de Bono.
Carpe Diem.
Where n is PI... Hmmmmm Pie!
Man who stand on hill with mouth open wait long time for roast duck to drop in
-
Consistently bad. I create a list of high-level tasks, break them down into smaller tasks, and estimate the time needed for each based on past experience... The end sum is almost always half of the actual time needed once all is said and done... ...Of course, if i anticipate this discrepancy and double the final result, it'll still end up being wrong by about the same margin. It's like i work slower when i think i have more time...
Shog9 wrote:
I create a list of high-level tasks
That tends to be my problem to start with - client cannot define the result they expect. I'm currently in a build it and see what we get then we'll have another go. However I am NOT on a fixed price and some of the requests are doozies.
Never underestimate the power of human stupidity RAH
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
Awful; too many times my projects took six months longer than I had estimated. So now I just say that... e.g. "It should take me two weeks, but it could take six months longer than that."
-
Have you ever given any estimations to your project lead/client/customers? If yes how far off were they. If you are able to give accurate estimates, how do you manage that. There general tendency I have found in programmers is to think that a particular thing is easy and it might take less time. But I have found that getting stuck in things that look simple does more to throw you off estimates than complex things.
Pretty good but then I give best and worst scenario and how certain I'm on them, eg. "A will take 3 days with 75% and 6 days with 25%". This show that I'm pretty certain but there are some question marks. If I instead had said "3 days, 95% and 4 days 5%" I would be very surprised if it took more than 3 days. In the same way I can say that I'm not very comfortable with a task "3 days at 25%, 6 days at 75%". It might go easy but there could also be a major problem... When the full project is completed, I'll go through all my estimates and tries to deduce why the correct ones were correct and the others not... During a project and I happened to make a grave misjudgment I'll adjust all my other estimates of the same category, eg. not all of them. I't could be that I totally screwed up and thought library so and so was much easier than it turned out to be but that shouldn't influence my estimates for some other library (unless from the same source...) /Jonas ps. When I don't have a clue, I'll make some WAG and multiply with the optimistic coefficient PI... ps2. Don't forget to add time for transition between project and non-productive time (such as lunch, sleep etc) when summarizing.
-
Shog9 wrote:
It's like i work slower when i think i have more time.
I think it is a problem with everyone.:)
In my opinion it doesnt count as a problem. When programmer knows there is alot of time, work "speed" might appear slower than when in pressure. But that shouldnt be abused that way, under pressure is a state that doesnt last very long. Maybe few years max? Make too tight estimates and too close deadlines and your programmers work faster just to find them become dull and unspirited in the end, for working years very hard and accomplish actually nothing more that could have been accomplished with normal phase. Cheated them, Ha!