|
Xiangyang Liu wrote: That sounds so irrational
And for that, you get a 5, sir! 
Cheers,
Vıkram.
After all is said and done, much is said and little is done.
|
|
|
|
|
Interesting, I had a college professor told me to multiply my estimate by e (roughly 2.3). PI might be more reasonable these days.
Brent
|
|
|
|
|
So roughly,
Est(t) = (8h * (DateDue-DateNow) x NumberOfPagesInBrief x NumberOfClientEmployeesInvolved x PI ) / (1/e x NumberOfDevelopers)
Simple 
|
|
|
|
|
I agree with Marc, you can have an honest estimate which is not accurate. In addition, there is fairness. That is, an estimate that is both honest and accurate can be unfair, and vice versa.
Let me explain. According to my observation, developers in the same team get roughly the same pay, but their abilities vary greatly. One good developer can easily do 5 times the amount of work of an average developer. Plus, there are hard tasks that can only be done by some developers not others.
If I give an estimate of 10 hours for a task which will take others developers at least 20 hours to complete, however I can do it easily in 5 hours, then the estimate is fair but neither honest nor accurate in my opinion. If we must give honest and/or accurate estimates, then the few exceptional developers will be so miserable that they will either leave the team or die early.
It is easy to say that we should pay developers fairly based on their contributions, that almost never happen in reality, unfortunately.
-- modified at 14:43 Tuesday 10th July, 2007
|
|
|
|
|
Xiangyang Liu wrote: According to my observation, developers in the same team get roughly the same pay, but their abilities vary greatly.
I've noticed that too. You bring up a very good point.
Marc
|
|
|
|
|
In my current project I made an estimate for approx 1 month (with no "buffer" at all) and the managers say they would like it finished in 3 weeks. Well, I would like to be able to play the piano too, but most of the time wanting something to happen doesn't mean it will happen 
|
|
|
|
|
What happened to me sometimes is, another developer was assigned the job, he/she gave an estimate and started to work on it. After using 80% to 90% of the allocated time, the management realized that there is no way it can be done in time by this developer, so I was asked to takeover. Somehow I managed to redo the work with no extra time added. I can imagine what goes on in the management's mind:
"Wow, we should definately give him more work to do next time"
instead of
"Wow, we should definately pay him more".
|
|
|
|
|
Estimating cost and time for a project has never been my strength, but I have gotten better over time. I think the wording of the question and the answers is a little bit misleading. At least to me, part of estimating a project requires some sort of understanding of the client/stake holders and how they behave in the context of a software project. "Padding" is a poor word for risk management. The less I know the client/stake holders, the more risk there is, and risk in software projects is always measured in time. The more comfortable I am with the client, the less risk there is. (NOTE: less risk does not mean fewer changes, better specs, etc. It just means that there are fewer unknowns. With some clients/stake holders a well-established "known" may be that they are prone to radical changes and poor specs.)
Ultimately, I chose option #1 because I always give my best most honest estimate. However I have learned that software development is much more than writing code, writing tests, running tests, etc. SD is all about communicating with people. At this point in my career, I spend much more time working with my clients than I do writing code, so a major part of the time estimate is based on that communication.
That's my 2 cents.
|
|
|
|
|
"I estimate as accurately and honestly as I can" ... but I tend to take six additional months.
|
|
|
|
|
 That’s why I use my personal programmer’s calculator: Estimated Time x 3. Unless it is really simple then I use ‘x 2’,
The estimated time is based on my experience and abilities. The ‘x 3’ is based on reality: research, testing, debugging, change request, etc.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Yes, that is also my experience.
Adding more tim upfront does not help: The stakeholder use this as an excuse to push new features in.
Failure is not an option - it's built right in.
|
|
|
|
|
The problem I have with time estimates is I have to have a general idea of who is doing the work. Sometimes I multiply by 3 what it would take me to allow for a junior or less experienced programmer. Sometimes it's 1.5 or so. When fires need put out, though, it can really muck things up. I'd rather use cost than time, but since my employer is internal, nobody cares about cost except during the salary review... In which case we make too much because not even the production guys get paid that much, therefore we need to work more overtime.
For my consulting I do part time, it's easier in that I know I'll be doing the work, but I'm not as familiar with the processes.
Can't I just lift the line from the Agony and the Ecstasy?
Pope Julius II: When will you make an end?
Michelangelo: When I am finished!
Wes
http://www.21concepts.com[^]
-- modified at 10:04 Tuesday 10th July, 2007 Changed wording to not offend.
|
|
|
|
|
Wes S wrote: The problem I have with time estimates is I have to have a general idea of who is doing the work. Sometimes I multiply by 3 what it would take me to allow for a junior or low level guy.
I think I have seen more problems with senior and high level guys. 
|
|
|
|
|
Thanks, Xiangyang. I worded that horribly. It should be less experienced programmers...
Wes
|
|
|
|
|
|
One can be honest but completely mis-estimate.
The question asks "how honest..." but the answers are for the most part "as accurate..."
Furthermore, adding a buffer for a margin of error is not dishonest. It is realistic with the expectation that problems and changes will arise. And if you're a consultant that bills hourly, it doesn't matter to the client if you add the margin but don't use it. What matters is that the client has a ballpark figure for their budgeting and that both people have an consensus on what they expect and what constitutes a budget/time overrun. (Rarely are there under-runs).
The question of honesty is an interesting one in itself, but the question of "how accurate are you when you compare your estimate with the actual time/cost" is much more interesting. Too bad the survey wasn't worded well, IMO.
Marc
|
|
|
|
|
Marc Clifton wrote: Too bad the survey wasn't worded well
This is new(s)?
Grim (aka Toby) MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
(0 row(s) affected)
|
|
|
|
|
Honestly, and accurately stated. I find whether reading your CodeProject articles, or posts, they are always helpfull.
|
|
|
|
|
Yeah, what's the difference between #1 and #2 and #3 here. Don't accurate estimates require a buffer? What's the difference between and "small" and "large" buffer? Isn't a large buffer just a really good way of saying that you don't really know how long it takes?
All of the other answers sound dangerous to one's long-term job health. If the client can't afford your quote, then you're asking for trouble. If you stretch the budget on your client, then you're playing the game of eventually getting caught, especially when someone underbids you or the client starts getting angry with your work (may not be your fault).
And really, repeat business is way more valuable then new business, so isn't the long-term strategy to do whatever it takes to get repeat business? Seems to me like the strategy is an "honest" estimate that they can afford and honest work that they will appreciate.
|
|
|
|
|
I agree; an honest estimate can be completely wrong. If I am doing the work, I have learned that I need to at least double the time I believe I can accomplish the task in.
The idea of estimating the time at which someone else can do the same work, frankly, scares me. Before I can do that I need to talk to them and see their pasted work. I have never worked for a large company, so I have always known the abilities of those I was working with. Without passed performance information it is all guess work any way, the various equations are just a way to make a more structured guess.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Very well said. See my comment in a new post.
|
|
|
|
|
cause i have to lie or they will put an almost impossible deadline. Uh...Especially when they put you on the spot and expect a reply in a matter of seconds.
|
|
|
|
|
nardev82 wrote: Especially when they put you on the spot and expect a reply in a matter of seconds.
This is the hardest part for me. Without looking at the code and doing some preliminary design I find it very difficult to guess how long it will take to add a new feature. On top of that I find it almost impossible to forecast how much debug time will be needed as bugs are sometimes very difficult to find in multithreaded applications. I usually end up giving a bug free estimate with a small fudge factor.
John
|
|
|
|
|
I mean, some of the people (I refuse to bend and call them developers!) are waaaaaaaay of the mark. You'd think they were estimating for the three gorges dam..
There are 10 kinds of people in this world. Those who understand binary and those who don't...
______________________
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook
|
|
|
|
|
Give estimate way longer than when they need it ready and then when you succeed you seem like a miracle worker.
"But captain it'll take weeks to get those warp engines back online"
"You have 24 hours"
"I'll do my best captain"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
