News for hackers. Stuff that matters.
Re:Hard-to-swallow truths they won't tell you about software... by guappa on Wednesday November 08, 2023 @07:03AM (#38189269)
It's called "estimation" because it's not supposed to be precise.

Of course the only way to obtain a precise measurement is to start the clock and do the thing.

Re:Hard-to-swallow truths they won't tell you about software... by porker on Wednesday November 08, 2023 @07:07AM (#38189306)
And yet in the politics of a company, an estimate becomes fact, and then if you don't meet it they are angry.
Re:Hard-to-swallow truths they won't tell you about software... by guappa on Wednesday November 08, 2023 @07:09AM (#38189327)
Am I the only one who watched star trek?

Estimate, multiply by 4, give the number.

Re:Hard-to-swallow truths they won't tell you about software... by Hikikomori on Wednesday November 08, 2023 @07:39AM (#38189583)
It will take 4 units of time, time units are subjective.
Re:Hard-to-swallow truths they won't tell you about software... by GaelFG on Wednesday November 08, 2023 @08:12AM (#38189875)
I dont know if you are joking but when managing i do exactly that and that work (with a factor of 3 to be precise, with most people, some aldready take that into account). Works also with myself, i askmyself 'how much i think it will take, i double it and i assume half the day i will be bothered by other unplanned things'. It work remarkably well especially for longer projects.
Re:Hard-to-swallow truths they won't tell you about software... by guappa on Wednesday November 08, 2023 @09:06AM (#38190458)
Re:Hard-to-swallow truths they won't tell you about software... by benhurmarcel on Wednesday November 08, 2023 @09:35AM (#38190840)
I was always told to multiply by pi. Results that are not round numbers look more thought-out.
Re:Hard-to-swallow truths they won't tell you about software... by sometimesweenie on Wednesday November 08, 2023 @11:27AM (#38192708)
Much like estimates, pi is irrational
Re:Hard-to-swallow truths they won't tell you about software... by arethuza on Wednesday November 08, 2023 @11:42AM (#38192956)
And pi squared if it is a new team doing something new...
Re:Hard-to-swallow truths they won't tell you about software... by lucumo on Wednesday November 08, 2023 @11:03AM (#38192313)
There's a three-pronged approach when dealing with it:

- Pad.

- Communicate risks.

- Communicate assumptions.

Then when assumptions are wrong, immediately communicate that this will change the estimate. When risks hit, communicate that a risk hit, and whether or not you can absorb the impact in the planning. If not, communicate the expected delay. Pad that too.

Communicate, communicate, pad, and communicate.

(Padding, BTW, may feel dishonest, but it isn't. It is making the assumption that a certain share of you risks will strike and making allowances for that.)

If you still get in trouble for missing estimates, pad more and communicate in writing. Then when people start blaming, you can point to the emails sent. To their/your boss if necessary.

Re:Hard-to-swallow truths they won't tell you about software... by Volundr on Wednesday November 08, 2023 @12:51PM (#38194162)
> (Padding, BTW, may feel dishonest, but it isn't. It is making the assumption that a certain share of you risks will strike and making allowances for that.)

This. It helps to realize that when someone asks "how long will X take". What they are actually asking is "When can I rely on X being done by?". If you say 2 days and it takes one, no problem. But if you say one and it takes 2, they've already told the client it'll be done tomorrow, arranged for the machinery to be in place, and now everything is jammed up based on your delay.

Estimating is as much art as science and requires understanding the context around the estimate and how it will be used.

Re:Hard-to-swallow truths they won't tell you about software... by PH95VuimJjqBqy on Wednesday November 08, 2023 @01:01PM (#38194319)
also offer alternatives, preferably at the same time you communicate the risk. When the risk hits you can then start making recommendations about the workarounds you've already communicated.

This stuff is fluid but too many technical people feel as if it's not.