How do you estimate time
-
A slightly serious answer. Split it down into easily manageable task. Estimate each task. If the estimate is less than 1/2 day, round up to 1/2 day IF the estimate is greater than 2 days, split it into smaller tasks. Add the total. Multiply by 2 if I am doing it, or three if someone else (not because I am better but because there needs to be additional time for them to interpret, and for contingency if I missed anything) Round up to the nearest week or day depending how big it is. Add a couple of days for contingency. Present the estimate. Be prepared to negotiate. Note my time as I develop against each of the tasks - so next time I will be able to estimate better.
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
When I was working for a machine tool company in Dorset, we were all trained in the Carnegie Mellon University 'PSP' scheme. PSP stands for Personal Software Process. During the course we wrote our own statistical analysis apps and applied them recursively to the work. The PSP yielded lots of very interesting stats about our individual performances, but in particular it revealed nuggets such as spending more time on detail design reduced bug fixing, particularly in testing phase. Testing bugs take (if I remember) 5 times longer to fix than Compile bugs. In addition to exposing and improving the way you work, PSP builds a database of your performance which is your property(between jobs too), and provides a statistically significant estimate of future performance of jobs. You can use this to provide management with a probably accurate estimate. If you're really serious about this, I'd recommend:cool: PSP.
-
How do you estimate time fir writing code? If your manager ask you to give him a time for something to be done?
My Name in English[^] Translation done By OriginalGriff
-
Evidence Based Scheduling[^] :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Yet another reason to get FogBugz
Politicians are always realistically manoeuvering for the next election. They are obsolete as fundamental problem-solvers. Buckminster Fuller
-
i thougt 50. using your formula i calculated 156... now i´m thinking about the measure... is it minutes, hours or what? :^) finally, i chose "days"... quite relaxing for me, but not for the Manager... :-\
Clodetta del Mar wrote:
is it minutes, hours or what?
All of them: 156 hours, 156 minutes, and 156 "what?" (although I'm sure your manager will helpfully provide most of those ;) )
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
When I was working for a machine tool company in Dorset, we were all trained in the Carnegie Mellon University 'PSP' scheme. PSP stands for Personal Software Process. During the course we wrote our own statistical analysis apps and applied them recursively to the work. The PSP yielded lots of very interesting stats about our individual performances, but in particular it revealed nuggets such as spending more time on detail design reduced bug fixing, particularly in testing phase. Testing bugs take (if I remember) 5 times longer to fix than Compile bugs. In addition to exposing and improving the way you work, PSP builds a database of your performance which is your property(between jobs too), and provides a statistically significant estimate of future performance of jobs. You can use this to provide management with a probably accurate estimate. If you're really serious about this, I'd recommend:cool: PSP.
Thanks for mentioning this. I have made lots of estimates over the years but am still not very good at it. I've never tried actually analyzing the data though - will look at this shortly.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
My technique isn't too far from that:
- Take a wild-ass guess at the time it would take if I were certain the requirements were firm and that there would be no interruptions while I'm working on it;
- Double the number;
- Promote the unit to the next higher value.
So if I figure I could knock it out in an hour under "ideal" conditions, I estimate "2 days." If my wild-ass guess is two weeks, I submit an estimate of "4 months." And so forth.
The remarkable thing about this approach, which I first suggested as a gag of sorts, is that it's proved to be pretty reliable in practice -- seldom more than about 10% from the actual time required, and never more than 25% off. Somehow it accounts flexibly for requirements changes, imposition of unanticipated constraints, distractions and interruptions, and acts of God. There's a lesson in there, somewhere...
(This message is programming you in ways you cannot detect. Be afraid.)
-
How do you estimate time fir writing code? If your manager ask you to give him a time for something to be done?
My Name in English[^] Translation done By OriginalGriff
(MyEstimation + 15%)*2, well, ±...
-
Richard MacCutchan wrote:
Think of a number, add 2 and multiply by 3.
After giving it some Deep Thought, I'll start with 12. :rolleyes:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
How do you estimate time fir writing code? If your manager ask you to give him a time for something to be done?
My Name in English[^] Translation done By OriginalGriff
Usually I take a guess at first using the spec completeness and complexity and then I multiply by 2 or 3 depending on my knowledge of both the code and the architecture. How else do you expect to be seen as a miracle worker === Scotty STNG :laugh:
-
(MyEstimation + 15%)*2, well, ±...
-
How do you estimate time fir writing code? If your manager ask you to give him a time for something to be done?
My Name in English[^] Translation done By OriginalGriff
-
Experience. It's not an exact science - it's guess work based on "how long this took me last time" plus a bit of "how accurate and complete is the spec?" with a soupcon of "what else do I have to do at the same time?" and some extra "padding time to make me look good". Occasionally there is also "How much am I being paid for this?" and "how much do I like this guy and want to do this?" Complex. So about 8.73 working days, probably.
-
Remember to offer to your customer (or boss) that they can get it done (1) fast, (2) cheap, or (3) good. Pick any two.
-
How do you estimate time fir writing code? If your manager ask you to give him a time for something to be done?
My Name in English[^] Translation done By OriginalGriff
محمد م. محمد wrote:
How do you estimate time fir writing code?
Badly
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
-
How do you estimate time fir writing code? If your manager ask you to give him a time for something to be done?
My Name in English[^] Translation done By OriginalGriff
There is something called COCOMO that was developed and used almost 30 years ago to estimate time although it may not be applicable exactly to your work. However, its approach of taking into account many various technical (e.g., estimated number of modules or lines of code) and human (e.g., number of developers on the team that are skilled and familiar with the technologies) factors is going in the right direction. But not matter what estimates are produced, management will browbeat the time downward and the development team almost always work like hell to meet the deadline.
-
محمد م. محمد wrote:
How do you estimate time fir writing code?
Badly
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
-
Shelby Robertson wrote:
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him.
:Smile:Are you referring that all agile people are males?
My Name in English[^] Translation done By OriginalGriff
محمد م. محمد wrote:
Are you referring that all agile people are males?
Yes. I think its illegal to shoot female software developers, as they are an endangered species.
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
-
How do you estimate time fir writing code? If your manager ask you to give him a time for something to be done?
My Name in English[^] Translation done By OriginalGriff
I start by estimating a number based on experience. I only use factors of ~2. e.g. 1h, 2h, 4h, 8h, 1d, 2d, 4d, 2w, 1m, etc. Anything more specific is just a guess. Then I quadruple it. 1/4 is to make up for the fact that I'm lying to myself about how long it will take. 1/4 is for when I come across bug X in component Y and waste a day or more on it. 1/4 of that is so I can properly document the project, code, and write a developer's manual. I am meticulous about keeping track of my time, and lately I have been within 10% of my estimate. :cool:
-
How do you estimate time fir writing code? If your manager ask you to give him a time for something to be done?
My Name in English[^] Translation done By OriginalGriff
It doesn't matter how you estimate it, because whatever you think it will take you, it'll take longer... Or just come up with a guesstimate and multiply it by two.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
How do you estimate time fir writing code? If your manager ask you to give him a time for something to be done?
My Name in English[^] Translation done By OriginalGriff
I used to get stuck doing estimates, turns out I was fairly good at it, even though I hated every minute of it. They made me estimate the pieces and then brick them into a Microsoft Project file. I always gave them a tirade about how stupid that was, complaining all the while about what I called "Horizon Effect" (You see the mountain you want to climb in the distance, you bring pitons, ropes, and supplies, but after you get over the horizon you find that deep canyon and the fast running river running through it. Oops) But then I'd do it. Can't say how I did it. I'll guess that I looked at the complexity and could somehow estimate the volume of code which translates to how long it will take to write it. But that's experience talking about doing something similar to what I've done before. If it is totally new, all bets are off, that requires research and you don't know how deep that rabbit hole goes.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
