Hacker News Reader

Comment by ktRolster | Hacker News Reader

His point is that "Objectively estimating program size/complexity is not possible." The 'objectively' qualifier is important.

And while that's true, it's not a very useful result. There is a large subset of programs that are easy to estimate. If someone says, "write 20 standard CRUD services," most people can accurately estimate how long that will take. There is nothing tricky there. If someone says, "write a program to solve Goldbach's conjecture," then it is true, you can't estimate how long that will take (maybe someone can, I don't know how).

In practice, for the kinds of tasks programmers usually do, experience shows that 90% of the time we can estimate correctly.

View on HN

Of course if you ask most developers to estimate writing 20 standard CRUD services they will decide it's much more efficient to write a CRUD service generator instead of wasting time manually coding 20 services. Only to realize months later that creating the domain-specific language and code generator is 30 times harder than they anticipated, and they still haven't delivered even one working CRUD service.

Are you my biographer?

Imagine you've lost your keys. You've already looked everywhere for them. Now how long will it take you to find them? This what software estimation feels like to me. Simple tasks regularly turn into "find out why this simple code doesn't work". From there, you have no idea whether the solution will come in minutes, weeks, months or never.

It is still usually necessary to at least try to estimate as well as we can. And the higher level the task, the more the "detailed crap" averages out. But it is still not easy. And delivering software on time is usually as much about changing the spec as it is about doing the coding.

I don't even know that "detailed crap" averages out, because crap happens at all scales.

For example: we launched into an embedded project and were ticking along nicely, and suddenly discovered that we actually had to program a whole extra device, which we had thought came with all built-in firmware.

You need to increase your estimate to deal with such uncertainties. Don't think of it as "task will be finished at exactly time X," instead think of it as, "95% sure that task will be finished before time X." Give yourself padding so you can finish comfortably.

I'd quite like to work wherever you are now. I've never seen anything close to 90% of estimates on tasks being correct estimates.

I've posted this before, but it teaches how to get to that point: http://www.jamesshore.com/Agile-Book/estimating.html

Most teams fail because management uses estimates as a way to get underlings to work harder. When that happens, estimates will never be accurate.

Reply on news.ycombinator.com