The curse of estimates

Experts are cursed. In my experience — the more a person knows, the more she is unsure when asked for an approximation in terms of time for the task at hand.

This can be quite challenging situation, since the majority of clients/investors are not able to deliver fully developed specs. Most of the time, they just tell you what they envision in general, and you’ll have to figure it all out by yourself. If you are not reacting promptly, in many cases you loose a prospect.

In fact, prospects are right. They hire you to create magic from their random thoughts. The only problem is — you can’t charge your know-how separately. But I digress.

All professions on the web are infected by the correct estimate syndrome. Perhaps because I’m at the front-end side of things, I perceive back-end people are more into this epidemic than designers or front-end developers. I rarely ask front-end people, since I already know what can be done at what cost and in what time. So take my claims with a grain of salt.

Designers as a more irrational people are giving the estimate by their gut feeling or quite often already have established prices for various deliverables.

Programmers are rational and concrete, so they are always trying to give the exact estimate. I dare to send a message: we need such a precision only and exclusively in your work. The time programmer spends on discovering how things work, should be calculated in the estimate. I strongly believe that anything can be disassembled in matter of days, if not hours.

Features that clients request are almost always invented before. Clients are occasionally surprisingly informed and educated, but very rarely with a true authentic concept. My logic tells me — we are re-factoring what have already being adopted on the web. We should be familiar with 95% of the requested features or tasks.

Unless it’s something completely new. People are telling me The new things are fun to work with. I hear that all the time. So I have a second-guess that the estimate in terms of billable hours is not applicable here.

As I see it — you work repetitive tasks for money, while you innovate for fun and personal growth (and so you can make more money later, when the feature becomes popular request or part of a standard package).

For any task, there is the worst case estimate, the super-optimistic case estimate and the estimate by experience. Experienced expert should know:

• what can go wrong
• how fast she can do it, if she is in the right mood
• how much time and effort some similar task(s) took her in the past

This is, of course, my point of view. What’s your approach on this?

Addenum

Snook lists the most common tasks a true web developer has to go through in A Web Developer’s Personal Projects.