The results of Jeff's
estimation quiz are
now available.
I managed to get 3 good answers out of 10, while the goal was to obtain
9 answers within the boundaries. The conclusions are rather obvious:
- Estimating what you don't fully understand means nothing, and too often
software estimates are made at a stage in a project where all
technologies aren't mastered well enough.
- Everybody has a tendency to make estimate ranges too narrow, either because they think it makes them look bad, or it odes not serve the purpose of an estimate.
For the moment, estimates I make don't have a huge impact. I can
release the software I make anytime I wish. In my previous job, it was
a little bit more important, since press releases, newsletters and
advertising were synchronized with a new product's release, and you had
to submit advertisement two months in advance. You better deliver the
product in time, but you have enough time to raise a "no go" and delay
marketing. On the contrary, I've often experienced that it's marketing
which delays software releases.
Still, it's nothing compared to consultants who sell their services to
companies. Estimation errors can lead to zero profit and unpaid extra
hours. That's why I don't think it's a big deal that Microsoft is
delaying the release of Vista (or other products). People who like
Vista will buy Vista anyway, sooner or later.
For software development, I believe the first estimate worth
considering is the one made after prototyping. You have played with the
important technology ingredients required in your project. That's why
prototyping is really important. It's also a way to test your whole
team's strengths and weaknesses. Even then, software estimates require
constant revision, as you continue to learn from the development you
make. Jeff's
recommended book
says this also impacts productivity, but I disagree. Once prototyping
is done, you must make a final choice about the technologies you'll be
using, and stick with it! What affects estimates the most is the
feature set changing during development, either because developers
implement features that weren't on the target list, or the customer
always wants more. In the first case, developers (me first) have a
tendency to think that easy to implement features don't impact
estimates. In the second case, the customer (real customers or the
marketing) too often does not know what he wants until he can see the
product. Always plan (at least) two versions for your product, and
don't let your customer add new features for the first release.