3 ms·

Estimation is a problem of horizons. Before you begin, the solution is N horizons away. You don't know what N is, and you don't know what's over the first horiz

• joe_the_user 10y ago
  That is the problem of any-old-estimation-problem. I think that the way a software engineering estimation problem feels is that you begin with N component that will combine to create the cost. You add or multiply the components together to get your estimate. It seems reasonable. Then suddenly one of those components turns out to contribute ten times as much to the cost and your estimate is doubly shot, shot in terms of time and shot in terms of what you will be spending your time on. These two parts things together tend to make bosses and customers unhappy. It would be nice if one had mathematical insight into such process. Unfortunately, I'm not sure how much big-O-type analyses give us, since they're worst case scenarios. By the halting problem, we know there's no general way to determine if a given program we start is going to crash. Yet we produce mostly bug-free programs, at least sometimes.
• nradov 10y ago
  This is why in agile development we don't even attempt to make precise, committed estimates beyond the first horizon.