I don’t know the origin of that saying. When I first heard it, it was presented as ancient Chinese wisdom. In the West we often attribute pearls of wisdom to some named or unnamed ancient Chinese philosopher. I suspect many of the attributions are not historically accurate. In any case, the saying suggests — correctly, I think — that by examining the past we can make some predictions about the future…within limits, of course.
One of the hot topics of discussion in software development circles these days is the question of how we can make useful predictions about the future for purposes of planning software delivery activities. The subject turns out to be trickier than I had, um, predicted.
Most of the confusion appears to arise from assumptions different people hold. The largest break in mutual understanding, as I see it, comes from different assumptions about the level of abstraction at which we need to make predictions.
People whose direct personal experience is in mid-to-upper management tend to think of prediction as a tool to inform the "go / no-go" decision for a development project. "Will we be able to deliver this product in time to matter and at a cost that makes it worthwhile?" People whose direct personal experience is in software development or line-level project management tend to think of prediction as a tool to inform short-term planning, as in "how much of the planned scope can we complete in the next week / month / iteration / release?" When people who have different assumptions argue that this or that method of prediction is or is not useful, they talk past each other because they are not thinking of the same problem.
Another source of confusion is the different working definitions people have of key words. In the software development field, we often think of making predictions as "estimation." Some people understand the word "estimation" to have something to do with predicting how long a piece of work will take, usually based on a judgment informed by past experience. Others understand "estimation" more broadly as any method of making a prediction about the future, including judgment-based, measurement-based, and commitment-based prediction. When people who have different assumptions argue that this or that approach to estimation is or is not useful, they talk past each other because they have different working definitions of the word, "estimation."
For purposes of short-term planning, people mostly seem to advocate one or a combination of the following approaches: estimation, projection, and commitment. Each of these words seems to carry far more emotional baggage than one might expect and, in my opinion, more than is warranted. Here are the working definitions that I, personally, apply to these words:
- Estimation generally means that people make a judgment about how long a piece of work will take to complete based on their direct personal experience in doing similar work.
- Projection generally means using historical data to calculate the likely delivery capacity of a team over a period of time, typically using a sliding window of recent history of mean cycle time or average velocity.
- Commitment generally means that team members promise to make a sincere effort to deliver some scope of work over a period of time, based partly on their best judgment and partly on their willingness to put forth extraordinary effort to deliver, possibly, more than their historical performance suggests they could normally deliver.
As it happens, I’ve gotten good results using all three of those approaches. When the work was of a routine nature and our team had recently done a similar project, judgment-based estimation was a very effective way to get a realistic idea of how long the new work was likely to take. When working with a team whose stakeholders requested work at a variable rate and whose work items tended to vary in size, using historical mean cycle time as the basis for projecting likely future delivery performance worked well. When working in a sweat shop environment where requested work was impossible to predict or plan using any conventional estimation or planning methods, making a commitment to hit a challenging deadline, even lacking information, worked quite well; we surprised even ourselves, and it was satisfying on some level. (I wouldn’t choose to work that way all the time, though.) There is a time and place for all these approaches, and probably others.
In any discussion of the subject, problems arise when different people have different working definitions in mind for the same words. In a recent Twitter exchange, I noticed that in an uncharacteristically passive-aggressive moment, someone I know (call him Person A) had disparaged the professional experience of another person I know (call him Person B) merely because Person B had made statements about "estimation" based on a different working definition of the word than Person A understood. To me, this indicates the word is emotionally loaded and therefore potentially dangerous.
On the other hand, a friend of mine suggested that if we try to avoid every word that might be misunderstood, we would soon be unable to say anything at all. Maybe that’s okay; maybe fewer words would result in clearer communication. At the very least, it would be an improvement over endless, circular bickering. That’s my prediction, anyway.