I recently had the pleasure of being asked to estimate a set of features. I was new to the customer’s system, hadn’t been involved in any of the steps leading up to the final requirements and was still working on fixing the bugs from another project.
I sat down with the specifications and roughly estimated how long it would take to implement the required features. The estimation that came out of this was roughly two days more than was originally planned for the complete set. I also asked for a complete part of the feature set to be removed from the list and made into its own project.
So, basically in the end, I estimated more time for less work than was originally planned. Not a good thing per se, but unavoidable. As the consultant or customer you might be trying to get the developer to estimate optimistically: „Do you really need that much time?“ „Are you sure it takes that long?“ „These are just basic forms, can it really be so much work?“
The answer to that is: Maybe not, but probably yes. In my experience in every project that’s at least slightly complex, there are pitfalls. There will be trouble. As a developer I try to be as optimistic as I can get about how long something will take. But I also need to take care that I don’t end up with an estimate that will collapse as soon as I encounter even a regular-sized problem. It’s finding the balance between customer service and self preservation that is the hard part here.
Basically, I won’t give you optimistic estimates. I can’t. I won’t. The best reason not to be optimistic is that in my personal experience it hardly ever works and in the end you either have to postpone the release or you end up with a low quality product.
There are also good reasons not to be pessimistic. One is that this is a bad state of mind. I don’t want to be pessimistic. Really. I’d rather not run into problems and work smoothly on a project. Plus, it never goes over too well with whoever is waiting for the project to get done and I’d rather work with someone who’s not suspecting me of being a lazy developer.
My approach is to be realistic and factor in the risks of running into problems. This includes identifying the spots where problems are most likely to occur and allow for some time to fix these problems. Of course I might be wrong there and it turns out that where I suspected problems everything works fine. Instead trouble pops out somewhere else. Or not at all. Or everywhere at once. Who knows?
One of the best quotes I read about estimates was somewhere on 37signals‘ blog Signal vs. Noise. I don’t remember exactly, but the gist is this: Estimates are guesses. Nothing more and nothing less. They are not promises. They are not random numbers. They are something in between. And they might be wrong.
The best thing I can do is try to stay realistic in my estimates and trust that you trust me enough. I can only guess anyway.
—
I can’t find the original quote that I had in mind when referring to Signal vs. Noise, but here are two interesting posts that deal with the topic: