"And the problem is that, hidden in the parts you don’t fully understand when you start, there are often these problems that will explode and just utterly screw you."
I completely agree! I also find myself telling my bosses that 80% of the feature takes 20% of the effort/time. Then a wall is hit and the remaining 20% takes 4 times longer (80% of the time).
ADD: And as you go along, the cone of uncertainty hopefully narrows but when you hit one of the exploding "we didn't knows!" your original estimated time/effort is too small. We try to account for these by including some "uncertainty buffer" but then the stake holders get mad when they see these large effort/time values at the start of a project. It seems stake holders don't really want to hear the truth and the possibly ugly, only the sweet sound of nothing going wrong.
Giving those the-stars-align-and-nothing-unforeseen-happens estimates do a disservice to everyone and/but then you have other developers/consultants/etc. competing and vying for work so they try to undermine and and undercut the more realistic estimates and we find ourselves in a downward death spiral similar to trying to compete on price alone.
I tell my bosses that before I can give a solid estimate I need to have two things done first:
1) I've eliminated most (or all) of the unknowns
2) I know how I am going to do the thing I am supposed to do.
Sometimes I know the system and I know how to implement what's asked. But if I'm working in some of the legacy code we have the above 2 tasks easily take about 50% of the total time.
A project I'm currently involved with suffers from a few things... 1) the unknowns never end as teh client keeps changing the freaking requirements! 2) they don't like our estimates and keep asking us to find another implementation to meet their requirements that requires less time and 3) they basically are trying to get us to implement the various solutions while "estimating", so basically we are doing the actual work while "estimating"... the estimate is suppose to be used for determining how much and how the development is to be paid... so we are burning non-billable time estimating (doing "the work") in order to shorten the estimated billable implementation effort. So the calendar date of delivery really isn't changing but how much is going to get billed is decreasing. And, if we try after doing the work "estimating" to say the amount of billable hours is more than the time to now deliver, they're going to say that can't be. Then we'll either have to dig our heels in and saw we did billable work while estimating or not collect on billable effort. It's so messed up. If I was in charge, I'd have fired the customer by now.
If I was in charge, I'd have fired the customer by now.
Some people don't know what bad business is. I find myself worrying less and less about the experience level of developers I have to work with and worrying more about the experience level of clients as clients.
I completely agree! I also find myself telling my bosses that 80% of the feature takes 20% of the effort/time. Then a wall is hit and the remaining 20% takes 4 times longer (80% of the time).
ADD: And as you go along, the cone of uncertainty hopefully narrows but when you hit one of the exploding "we didn't knows!" your original estimated time/effort is too small. We try to account for these by including some "uncertainty buffer" but then the stake holders get mad when they see these large effort/time values at the start of a project. It seems stake holders don't really want to hear the truth and the possibly ugly, only the sweet sound of nothing going wrong.
Giving those the-stars-align-and-nothing-unforeseen-happens estimates do a disservice to everyone and/but then you have other developers/consultants/etc. competing and vying for work so they try to undermine and and undercut the more realistic estimates and we find ourselves in a downward death spiral similar to trying to compete on price alone.