|
Don't drink tea, don't smoke. So no.
Coffee breaks are extra, natch.
|
|
|
|
|
Richard MacCutchan wrote: fag breaks They prefer to be called gay and openly admitting to attacking them isn't good form.
|
|
|
|
|
In the UK a fag is a cigarette.
Veni, vidi, abiit domum
|
|
|
|
|
In the US a fag can also mean a cigarette. I was kidding about it's other meaning. Drag changes based on context too, it could relate to a cigarette or a way of dressing. Strange language, English. Gay means happiness.
|
|
|
|
|
|
Think of a number, add 2 and multiply by 3.
Veni, vidi, abiit domum
|
|
|
|
|
So based on Griff numbers:
(8.73 + 2) * 3 = 32.19
|
|
|
|
|
Shhhh....don't tell everyone, that's our secret.
|
|
|
|
|
No, no, no! You are supposed to think of a number, not me!
|
|
|
|
|
Isn't it a slandered timing for writing code
|
|
|
|
|
Nope - stealing my numbers is plagiarism, not slander!
|
|
|
|
|
|
My lawyers will explain it all to you when they arrive.
Shouldn't be long now...
|
|
|
|
|
I'm out of here bye. Will deactivate my account
|
|
|
|
|
Please ask the admins to re-activate your account; OriginalGriff was just joking, as he said here[^]
|
|
|
|
|
|
I'm a slow coder.
Veni, vidi, abiit domum
|
|
|
|
|
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? Yes, of course.
Veni, vidi, abiit domum
|
|
|
|
|
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)
|
|
|
|
|
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.)
|
|
|
|
|
Richard MacCutchan wrote: Think of a number, add 2 and multiply by 3.
After giving it some Deep Thought, I'll start with 12.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Take the number they give you and multiply it by PI (3.14), for going around in circles.
|
|
|
|
|
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 PSP.
|
|
|
|