Building software is complex and wrought with uncertainty.

This is perhaps most commonly observed in the difficult task of estimating how long a particular software development task will take to complete.

One reason this estimation is difficult is that software is made up of tons of small, seemingly insignificant details, that add up to large, very significant details. And until those details are understood and specified, it’s practically impossible to know how long they will take.

So if we desire more accurate estimates of software development tasks, we’re often faced with the task of thinking about and specifying greater detail about the software we’re planning to develop.

But here’s the funny thing about software development: The act of software development is the act of thinking about and specifying greater detail.

That put us in the interesting situation, that the only way to get accurate about our estimates is to do the work that we’re estimating. I think we can go a bit further, in fact, and say: the degree to which our estimates about work can be accurate is directly correlated to the degree to which the work is done.

It’s an interesting application of the observer effect. As an example, if you want to measure the air pressure inside of a tire, the normal approach involves letting some of the air out of the tire, which in turn changes the air pressure.

In a similar way, the act of “measuring”, or estimating, software projects, changes the projects. And the more accurately we aim to estimate them, the more of the work we complete in that process.