{ by david linsin }

August 04, 2008

Honest Estimations

Have you ever sat in a meeting, estimating the time that you will need to implement a feature? With only a vague idea of what it's all about and someone wants to know how long it's gonna take, so you have to come up with a number? The other attendees seem to know exactly how things work: "Oh we've already implemented something similar, we can just use that" or "That's easy, I can code that in a couple of minutes". And you are sitting there with a strong urge to start a discussion about each estimation, because you have the feeling, that you are the only one in the room who sees things straight?

If this sounds familiar to you, then you probably already know that those estimated numbers are nothing more than a pipe dream.

Jeff Atwood said something to the point, in the stackoverflow podcast episode 16:
I think this is a really good point, is that your mind's eye tends to fill, you image the app as you want it to be. It's like "Oh how hard can it be, we're just going to plug in a login-thing here and I've done this a hundred times and it will take no time at all."...

I think it's the job of more than one person on the team to keep you honest.

...excellent point that you always imagine that it's going to be easier than it is, and you can't think through all the details that are going to go wrong, and all the wierd things you're going to have to think about until you actually start to do it...

Most of the time, when you think you can implement something very quickly, it turns out to be the opposite. Don't get me wrong, there are situation where it comes down to some copy-and-paste and that's it. However, I believe in most of those cases you haven't thought about the problem thoroughly and that copied portion of code will eventually turn into Quick Hack Bacteria.

I think you should get things done right from the beginning. I'm not talking about something like a waterfall complete upfront design! I believe in iterative processes, they work very well and sometimes it's just not possible to get things right from the start. However, I claim that it is possible in a lot of cases and those sloppy 5 minute hacks are not "getting things done", but "making things worse", at least in the long run.

I really believe it comes down to honesty and aspiration, like Jeff mentioned. Honesty in terms of how much work you can really get done in a certain amount of time and aspiration in relation to the quality of that work. If you take those two parameters into account, when estimating the time you will need to implement a feature, I think chances are high that you are going to come up with a reasonable number.


Anonymous said...

Do you know Steve McConnell's "Software Estimation"? Its tag line is "Demystifying the Black Art" and it appears to be the definitive reference on the topic. It's on my reading list because I'm not comfortable giving estimates either.

The best explanation I've found so far was in "Making Things Happen" (a great book, I recommend it). It's about project management and it says that each estimate comes with a probability of it becoming true. The more time you invest in the estimating process, the better your estimate typically gets.

In a project, things can get dangerous pretty quickly. For example, if you give three estimates for a project with a 80% chance of each being correct (pretty accurate, right?), then the probability of your project finishing as estimated is just over 50%.

It's pretty depressing.

David Linsin said...

unmaintainable > Steve McConnell's "Software Estimation"

Thanks for the hint. I heard of the book, unfortunately my reading list is really long...

Sebastian Kayser said...

I am watching the problem from a sysadmin perspective not as a software developer. Nevertheless, the challenge is the same.

The interesting thing here is that experience has probably told everyone that estimates like "oh that's easy" are not likely to come true during a project.

So, besides the obvious difficulties to estimate the unknown, IMHO there are two things essentially wrong in such a situation:

1) Lessons from former projects are not properly learned and really translated into "How do we things differently next time?". How about the lesson "You know that there's gonna be problems? You remember that last project, where you thought ...?!"

Project post-mortems come to my mind.

2) Estimates are given to please external demands (deadlines, budget, ...). or due to a lack of honest judgement "Oh, i can do that, no problem". Instead of asking ourselves and others "Are you sure? Is that realisitc?" we think "Perfect, everything is in line, let's get going", nod, and happily run down the same line that we went down so many times.

Shouldn't we be able to learn? Shouldn't we feel the responsibility to treat ourselves and others with honesty?


  • mail(dlinsin@gmail.com)
  • jabber(dlinsin@gmail.com)
  • skype(dlinsin)