I'm bad with time. One thing I hate doing is giving time tables on how long it would take to work on a project. It's not that I'm opposed to it's just I don't know how to calculate it, especially big projects. I was wondering if other people here have this issue and what do they do about it.
In my opinion this is actually pretty much impossible to do accurately.
Managers love to get time estimates, but you're lucky if you can get an accurate representation of the final requirements of the project when you start, let alone figure out how long it would take to implement them.
One rule of thumb: every non-trivial thing to do takes at least four hours. So break down your task into sub-tasks (if possible) and make certain that each sub-task has at least four hours allotted for it.
> I'm bad with time. One thing I hate doing is giving time tables on how
> long it would take to work on a project.
I'm very scientific with time estimations: let a manager or sales **** do
the estimation and then multiply the outcome by 'pi'. If they start protesting
against it, multiply that result by 'e' until they keep their mouths shut ;-)
kind regards,
Jos
> > I'm bad with time. One thing I hate doing is
> giving time tables on how
> > long it would take to work on a project.
>
> I'm very scientific with time estimations: let a
> manager or sales **** do
> the estimation and then multiply the outcome by 'pi'.
> If they start protesting
> gainst it, multiply that result by 'e' until they
> keep their mouths shut ;-)
>
> kind regards,
>
> Jos
Well they would then be keeping their mouth shut because they would be busy typing the employee's suspension letter.
I once had to work with a particular business dweeb. He asked for a sizing on a project, and I gave one, given certain assumptions which he basically verified before the estimate. He then spent an incredible amount of time changing things so they violated the assumptions, which would make things go over schedule anyway, even if we weren't spending all our **** time in meetings listening to him talk.
So when I had to do another project with this guy, I gave very long sizing to compensate for the time we'd spend dealing with him. And then he complained to my supervisor that the estimates were too long. My supervisor actually correctly guessed why I padded the estimates so much, and didn't support them. So I gave estimates that would have been correct if I had worked with a sane person, and guess what, we went over the estimates.
Estimates are impossible to get right for a million reasons. One reason is that you can be burdened with a time wasting douchebag without warning.
> I once had to work with a particular business dweeb.
[ ... ]
> Estimates are impossible to get right for a million
> reasons. One reason is that you can be burdened with
> a time wasting douchebag without warning.
Another reason is changing requirements: that same dweeb goes
all the nine yards using FPA (Function Point Analysis) and finally
figures out that a read only data window should take 1.75 hours.
When that thing is almost done the dweeb enters the room and starts
babbling and whining about buttons, data entry fields, changeable
report parameters and a textual query facility all in that same read only
data window and preferably all done in those same 1.75 hours.
I never understood why ignoramuses determine how much time something
should cost; when I tell them how much time their funky spreadsheets
and powerpoint presentations should cost, all I get are those surprised
and stupid looks ;-)
kind regards,
Jos
My rule of thumb:
Estimate| Multiplier
--+--
< 1 hour| 60
< 1 day| 20
< 1 week| 10
< 1 month | 5
< 1 year| 4
< 1 decade | 2
So, for example, an estimate of "a couple of minutes" will
be at least two real-world hours. An estimate of "oh, maybe
a day" will be two working weeks when testing and bug fixing
is taken into account.
Only slightly joking...
D.
> Only slightly joking...
IMHO that's the modus operandi of this entire thread ;-)
kind regards,
Jos
ps: a true little story:
R&D-manager: this problem, how long will it take you to solve it?
me: do you understand the problem?
R&D-manager: no, that's your job.
me: ok, fair enough; I never even thought about that problem.
R&D-manager: how long will it take to solve it?
me: dunno, is it solvable at all?
R&D-manager: that's your job.
me: ok my estimate is: anything between a month and never then.
Well, as you will have gathered from the above posts, nobody knows how to estimate the time required for a large project reliably. The remedy for that is... Don't estimate the time required for a large project. Break it into small pieces. Estimate the small pieces.
And no, the large project isn't just the sum of the small pieces. Don't get sucked into that idea. Once you have done some of the small pieces, you will find that the large project's requirements will have changed anyway. So resist the pressure to estimate the whole thing.
Yes, I know this doesn't work when you have to tell your customer you expect to charge them $13.7 million for their flight reservation system, but you should still resist as much as possible.
Well that at least makes me feel better to see others have the same issues. Most of my projects I work on alone and I don't punch a clock so I really don't have any estimates do go by since I never track myself. As far as I'm concerned there's too many variables. One of my biggest time killers is when there's a small bug I found and I have to back track it to find where it came from.
> R&D-manager: this problem, how long will it take you
> to solve it?
> me: do you understand the problem?
> R&D-manager: no, that's your job.
> me: ok, fair enough; I never even thought about that
> problem.
> R&D-manager: how long will it take to solve it?
> me: dunno, is it solvable at all?
> R&D-manager: that's your job.
> me: ok my estimate is: anything between a month and
> never then.
That's a nice story :-)
Never worked in the corporate environment before. I've written programs for small companies before and one other thing (I forgot to mention) I hate is when I try to query them about what they want and once the project gets moving then I get hit with their ideas. The small bug thing I mean is when you accidentally do something that doesn't cause a program to **** out or returns the wrong results and you can't figure out what caused it. One time I remember spending hours trying to figure out why a SQL statement wouldn't return any results, and looked through all the code trying to figure out what could be causing the issue. The statement looked correct, the DB seemed to have the correct results, etc. I thought one thing might have caused it then another, etc. What I ended up finding was that I used one curly brace instead of a parenthesis. In the code it was very hard to catch. However, since then I've learned to program far more modular. How dependent my methods were on each other (at the time) is what caused me my headaches.
Yeah debugging is usually the worst part of our jobs... it's like pulling teeth. Or more like pulling your own teeth. And the brief elation you get when you finally fix the bug only lasts for about fifteen seconds, after which you think "I've spent three hours because of one fucking missing comma?" or the like and you feel like you're wasting your life.
That's how it makes me feel, anyway.
Still though in terms of time wasted, I think in my corporate jobs anyway I've wasted more time in meetings than debugging.
> Still though in terms of time wasted, I think in my
> corporate jobs anyway I've wasted more time in
> meetings than debugging.
I once owned an HP Jornada/728 and implemented a tiny IDE on it
using Sun's "personal profile" Java and the old "classes.zip"; it allowed
me to debug while being at those boring meetings ;-)
kind regards,
Jos
> My rule of thumb:
>
> Estimate| Multiplier
> --+--
> < 1 hour| 60
> < 1 day| 20
> < 1 week| 10
> < 1 month | 5
> < 1 year| 4
> < 1 decade | 2
>
I have been involved in a small project that was planed to take about a week. The project was completed 11500 hours later. (No kidding)
> Yeah debugging is usually the worst part of our
> jobs... it's like pulling teeth.
I'm a freak. I actually enjoy debugging. I even enjoy debugging other people's bugs. The more intractible and inexplicable the bug, the more I enjoy it.
Which isn't to say that I put the bugs in on purpose (no challenge) but there's a crossword-puzzle sort of fun to be had in defeating them once they're there.
D.
> > My rule of thumb:
> >
> > Estimate| Multiplier
> > --+--
> > < 1 hour| 60
> > < 1 day| 20
> > < 1 week| 10
> > < 1 month | 5
> > < 1 year| 4
> > < 1 decade | 2
> >
>
>
> I have been involved in a small project that was
> planed to take about a week. The project was
> completed 11500 hours later. (No kidding)
Please tell me that is more than one developer involved in this project, as one week is normally 40 hours but increases with every extra body on it. If only one person was involved that means it took over 4 years (if my math is right) - that's a heck of a long week project.
> > > My rule of thumb:
> > >
> > > Estimate| Multiplier
> > > --+--
> > > < 1 hour| 60
> > > < 1 day| 20
> > > < 1 week| 10
> > > < 1 month | 5
> > > < 1 year| 4
> > > < 1 decade | 2
> > >
> >
> >
> > I have been involved in a small project that was
> > planed to take about a week. The project was
> > completed 11500 hours later. (No kidding)
>
> Please tell me that is more than one developer
> involved in this project, as one week is normally 40
> hours but increases with every extra body on it. If
> only one person was involved that means it took over
> 4 years (if my math is right) - that's a heck of a
> long week project.
The project started with 2-3 developers, and ended with about 10. It took about 1.5 calendar years complete the project.
The estimate was that 2-3 developers would be able to complete it in one week (that is, the estimate was about 80-120 hours)
> > > > My rule of thumb:
> > > >
> > > > Estimate| Multiplier
> > > > --+--
> > > > < 1 hour| 60
> > > > < 1 day| 20
> > > > < 1 week| 10
> > > > < 1 month | 5
> > > > < 1 year| 4
> > > > < 1 decade | 2
> > > >
> > >
> > >
> > > I have been involved in a small project that was
> > > planed to take about a week. The project was
> > > completed 11500 hours later. (No kidding)
> >
> > Please tell me that is more than one developer
> > involved in this project, as one week is normally
> 40
> > hours but increases with every extra body on it.
> If
> only one person was involved that means it took
> over
> 4 years (if my math is right) - that's a heck of a
> long week project.
>
> The project started with 2-3 developers, and ended
> with about 10. It took about 1.5 calendar years
> complete the project.
>
> The estimate was that 2-3 developers would be able to
> complete it in one week (that is, the estimate was
> about 80-120 hours)
One day when you have some time I would love to read about it, that sounds like the best project from hell that I have heard of thus far.
