HN Explorer

Ask HN: Why do programmers suck at estimating hours?

7 points by bikamonki ↗ HN
Is it even possible to do a good estimate?

All IT departments I've worked with are behind schedule.

All projects, medium to large, that I've worked on were delivered late.

Seems like making detailed specs and being more structured in managing the project using some methodology helps, but still, always late.

Is it just the nature of software development?

12 comments

[ 2.0 ms ] story [ 24.7 ms ] thread
mingabunga
I saw someone else comment another time, double your estimate of time and change the magnitude

2 weeks becomes 4 months.

greenyoda
Some reasons why my own estimates are off:

1. Requirements change frequently while the code is being developed. (If we had detailed specs, we'd be constantly re-writing them.)

2. People ask for estimates before I've had enough time to completely understand the complexity of the problem.

3. Higher-priority projects intervene, and when I go back to the original project (sometimes months later), additional time is needed to figure out what I was doing when I was interrupted.

Fortunately, my management understands that estimates are always going to slip in this kind of chaotic development environment. If we absolutely need to hit a release deadline, we usually start pushing less-critical features/fixes off to the next release. (I work on enterprise software that's sold to large companies, which has release cycles measured in months.)

kitsunesoba
In addition to these three, there are some things that simply won't be understood fully until you're in the middle of working on it, plus there are almost always unforeseen complications, edge cases, etc. Even if no major issues are encountered, having to deal with several smaller problems can slow down development significantly.

Non-engineers probably liken feature and project completion to a simple shot at a bullseye but it's really more like trying to hit a moving target at the end of a labyrinth.

thecupisblue
>1. Requirements change frequently while the code is being developed. (If we had detailed specs, we'd be constantly re-writing them.)

This, so much. People wouldn't change blueprint of a house being built 3 times in two months, but for software they act like it's not even a minor setback.

bbcbasic
You've never watched Grand Designs?
cwt
> 3. Higher-priority projects intervene, and when I go back to the original project (sometimes months later), additional time is needed to figure out what I was doing when I was interrupted.

This is major for me at my current employer. It is not always a project that intervenes. It is more along the lines of "stop everything and fix my problem(s)" requests that are deemed urgent.

mcdevhammer
Seems to just be the nature of it. Every single project I have ever worked on was delivered late.
UK-AL
How long will it take you to complete this maze?

You really can't tell until you've done it.

bbcbasic
One way to get super accurate estimates is to ensure that what you do is repeatable. For example get a developer to create the same web page time and time again with minor variations. And this will be very easy to estimate.

Therefore don't automate things and don't make things more efficient. That will help with estimation.

oolongCat
My biggest enemy against estimates is debugging, it is really easy to forget how simple bugs in a program can be the biggest time sinks.

--edit--

I guess this is something good programmers excel at doing, plus every-time get stuck with a time wasting bug, reminds me I have so much more to learn.

lucozade
In my experience developers are usually pretty consistent in estimating as long as they're in an environment that they have some experience. I don't mean they're usually right, I just mean that they're usually consistently optimistic or consistently pessimistic and by a relatively constant factor.

Also, and again as long as it's an environment your familiar with, the Donalds (the known unknowns) are usually relatively predictable i.e. you know the sort of things that will bite you and the sort of impact they have.

So I can usually estimate a project of 9-12 months duration to +/- a week or 2 as long as I've done at least a couple beforehand.

BTW that's not to say I always deliver on time. Depends entirely on who guessed the deadline and resourcing. But I can usually be able to be both annoying and smug by letting senior management know upfront how late they'll be and by how much.

Also worth pointing out that it's not because I work in a relatively static industry. Far from it. But if you have systematic errors then it makes sense to account for them. I do find it amusing that, in technical matters, most devs do this without thinking but seem to have a blind spot when it comes to planning or general project management.