
You Can't Do Software Estimates at All - SarasaNews
http://chrismm.com/blog/software-estimations-are-impossible/
======
douche
The one I love is being asked for an estimate cold on some feature/requirment
I've never heard mentioned before.

"How long will it take to add a feature to frobulate the fribbers?"

"What's a fribber, and what, exactly, does it mean to frobulate them?"

 _Handwave_ "How long? We need to schedule this."

"Can I do some research about frobulating fribbers and how one goes about
doing that?"

"No, we need an estimate"

"Ok, five minutes? Six weeks? Six years? Who the hell knows? What do you want
me to say?"

------
tyingq
Guessing this won't be a popular response, but all the hand-wringing about how
management is unreasonable to ask for estimates (cost or time) just isn't
helpful.

Anything a business is going to invest in needs some kind of justification,
and a metric to prioritize against other things the funds could be spent on.

I think it's fair to push back with suggestions that might make a realistic
estimate possible (reduce scope, proof of concept, etc). However, just
suggesting you can't provide any kind of reasonable time and cost estimate
doesn't help anyone.

~~~
b_t_s
I agree that businesses need estimates, but the problem is the form they take.
It's always "2 weeks", or maybe at a better place it'll be "2-3 weeks" both of
which are basically lies because they imply high confidence. What it really
ought to be is "2 to 3 weeks with X% confidence" because there's an absolutely
massive difference between "2 to 3 weeks at 90% confidence" and "2 to 3 weeks
at 10% confidence and at every place I've ever worked they both get treated
the same. The 10% confidence one might be roughly equivalent to "2 weeks to 6
months" with an implied high confidence but good luck giving an estimate with
that kind of range.

~~~
tyingq
That seems completely reasonable, and provides what a business would
want...metrics to make decisions on where to spend money.

The tack of the article was "Estimates can't be done". Which is silly. It
presents this analogy: "would it really have made sense to ask Einstein how
long he would take to find a unified theory of physics?"

I'm sure there's some small amount of software work that might fit in that
space. I would also guess that the vast majority of it doesn't.

------
Dr_tldr
Trying to prove the impossibility of something that is never going to go away
as a requirement isn't very useful.

An alternative would be to describe potential break-points and conditionals in
the planning process. For instance, if a third party library can help you with
some core functionality, it takes a few hours to investigate and an hour to
implement.

But if it's not going to work for whatever reason, then you know you have to
make your own, and the initial implementation could range from 4-6 weeks.

If you say "this will take either 4 hours or 4-6 weeks", that's far more
useful and acceptable to management than saying "this will take somewhere
between 4 hours and 6 weeks.

No one sane is asking for exact estimates, and no one smart is promising a
hard deadline based on the assumption that nothing goes wrong. A good engineer
will pad their estimate slightly for the same reason that airplanes carry more
fuel than the exact amount they need to reach their destination. It's not a
deceptive or inefficient practice, it's managing uncertainty.

~~~
thwarted
_No one sane is asking for exact estimates … It 's not a deceptive or
inefficient practice, it's managing uncertainty._

Part of the issue is that the asking for estimates ends up getting turned into
exacting time requirements as an attempt to control and manage uncertainty.
And often, many of the people who turn estimates into requirements are,
arguably, insane, because they are trying to manage the uncertainty in the
wrong way.

~~~
Gibbon1
I've taken to just telling my boss whether I think something is 'just work',
'tricky' or 'hard'. And about howm much of that he's asking for,

Just Work: Means are the pieces are there to do whats wanted. Tricky: Means I
need to create something from scratch or modify two or more modules. Hard:
Anything to do with timing, interrupts, or that involves re-organizing swaths
of unrelated code. Hard2: I have to learn a new language, frame-work,
microprocessor, etc.

------
dpweb
Companies have budgets so estimates are necessary. Volunteer or work in open
source if you don't like it. Those asking - business types usually - know (and
often care) little about the craft, so they can't be expected to be much help.

The best you can do is be experienced enough to be able to get it somewhat
close. Nothing wrong with padding. How much.. is an art form. But remember
technical people nine times out of ten, will under-estimate.

------
andyidsinga
some thoughts:

1) it seems that the accuracy of an estimate is inversely proportional the
length of time for which it applies. In my experience engineers aren't too bad
at estimating if a task can plausibly fit into a two week sprint

2) I think the boss should be taking an active part in the estimation process,
not just asking "how many hours/days".

When I estimate with my teams I try to say "given x,y,z and the current state
and that A,B,C blocks are not quite understood can this item reasonably be
completed within our sprint"

..then we play poker / vote / comment etc. If the item isn't plausible for a
sprint I'm (likeaboss) going back to the drawing board on that item to define
it better and get it into more manageable pieces (consulting the team as
needed)

We're striving to make sure work items are defined well enough to be fairly
confident they can be done in a short amount of time.

------
bonniemuffin
Still, some projects will take longer than others, and it's possible to
distinguish a 2-week project from a 2-quarter project, even if they actually
end up taking 3 weeks and 3 quarters.

I feel like comparative sizing is the most important part of software
estimates, so that you can make reasonable tradeoffs, e.g. "if we take on this
project, we can't do these other 2 smaller projects". This is still a valuable
exercise, even if all of the estimates are each individually quite inaccurate.

~~~
HeyLaughingBoy
I agree completely. It's the only way I've found that works. Start the
estimate by saying "these rolled-up, roughly estimated tasks come to about a
year in total."

Now we know it's closer to a year than to two months. Once we start, we can
continuously refine the estimate. "Sorry, there's a bunch of stuff we didn't
see. We can give you X functionality in a year, or all of it if you can wait
18 months"

Lather, rinse, repeat. With experience and good time tracking of tasks, you
learn how long things take: "every database we set up in the last year took
about 10 days to get right." Now you know your estimate to configure a
database and get it online is 10 days, not the optimistic "I can do it in an
afternoon" that everyone claims.

The key to good estimating is good historical data. Problem is devs hate
tracking their time and reporting accurately.

------
Retra
Well, maybe not if you're jumping to a new platform, API, framework, language,
or library each time you start a project.

~~~
HeyLaughingBoy
How long did it take to jump to the last new platform? How long for the last
new API, last new language, framework, library?

If you had historical data on how things went the last time you did these
things, you'd be better positioned to estimate how long it will take this
time.

~~~
Retra
Maybe if you're not making anything with any kind of novelty.

~~~
HeyLaughingBoy
At some point, everything is similar to something you've done before. The
difficulty is relating what you're doing now to what you did before.

If you go into it assuming that your work is some special snowflake that is
completely novel in all respects, you'll get nothing out of it. Find parallels
with what you've done before and you can actually make an estimate that's an
improvement over a SWAG.

