|
+5
great article....
whenever i was asked how long does x take i felt like i´m having my back on the wall...   
|
|
|
|
|
Yet another reason to get FogBugz
Politicians are always realistically manoeuvering for the next election. They are obsolete as fundamental problem-solvers.
Buckminster Fuller
|
|
|
|
|
|
محمد م. محمد wrote: How do you estimate time fir writing code?
There's the fundamental flaw. A time estimate needs to include more than just "writing code". Documentation, debugging, unit testing, feature testing, QA testing, rewriting...
So, break your requirements down into smaller chunks, recurse (and I do mean, re-Curse) until you feel like you can confidently make an estimation and if you can't, refine the requirements further. Then for every 10 hours of code writing, factor in:
1 hour for documentation
1 hour for debugging
3 hours for testing (unit, feature, QA)
2 hours for rewrite based on requirement changes and problems resulting from testing and having to update the tests and docs.
For every 500 hours of coding estimates, multiply the above additional factors by 2 to compensate for increasing complexity.
Marc
|
|
|
|
|
I try not to give an estimate, but when pushed I say they should add six months to my estimate.
This is based on experience, twice on a former job I gave an estimate:
In the first case, it turned out that a few systems we had been using turned out not to be Y2K-compliant so we had to get new systems, I had to learn to use them, and alter our code to use them.
In the second case, I thought that I could just drop some code into a new client's codebase (just as I always had), only to find that they were not using OpenVMS and Oracle PRO*C, but had instead opted for Windows NT and SQL Server (with ODBC ).
|
|
|
|
|
I'm actually glad you asked this question. This will help me as well. I've never been able to honestly estimate time. When I started working for the client I'm with at the moment, they repeatedly ask about how long I think some things may take, and I never really have an answer.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Tell him you do agile development now and the first iteration is 2 weeks.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
The project manager is going to always divide by 2 so I always times by 2.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
(MyEstimation + 15%)*2, well, ±...
|
|
|
|
|
|
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 
|
|
|
|
|
Remember to offer to your customer (or boss) that they can get it done (1) fast, (2) cheap, or (3) good. Pick any two.
|
|
|
|
|
|
محمد م. محمد 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?
|
|
|
|
|
محمد م. محمد 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:
|
|
|
|
|
Shelby Robertson wrote: I think its illegal to shoot female software developers
This sound nerdish
|
|
|
|
|
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.
|
|
|
|
|
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. 
|
|
|
|
|
Yvan Rodrigues wrote: 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.
Where did the remaining 1/4 go?
|
|
|
|
|
The first quarter is my initial estimate.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
If you think it will take an hour estimate a work-day, if you can do it in a day, estimate 5 work days, a week -> 2 months.
It's amazing how that works out to be pretty accurate. With the hour, you start coding, 10 minutes in, you go "what about..." You hunt down the guy who knows, get the answer. Start coding, someone asks you... By the end of the day snarl at anyone who dares approach you and finish the one hour project to be within estimate.
|
|
|
|
|
What do you do in a boring Saturday
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
