My mind seems to work in a funny way. A program’s quirk got me thinking about precision.

I tend to be overly organized. I use lots of folders to categorize: office, photos, movies, product management, presentations, humor, and so on. For a while I tried cross posting if you will, putting aliases or shortcuts in one folder pointing to the actual document in another. I think it is rather natural to try to categorize items. I know I should just throw everything in My Documents without any organization and let Google find them for me but I don’t. And invariably I end up with the same document stored in multiple places. I found a great tool for searching for duplicate files: zsDuplicateHunter, available for Macintosh, Windows, and Linux. I’m sure there are others but this is the one that I use. It’s amazing to me how often it finds duplicate files even when I think my computer is clean.

But here’s my point (finally). The program uses unnecessary precision. It tells me that the search has 47.6 seconds remaining. Why is the .6 relevant? For that matter, is 47 seconds relevant or even true? Isn’t “less than a minute” more accurate?

I learned about precision back in public school. 1 divided by 2 is 0.5. Period. In this instance, more decimals are not more accurate. Telling me 0.5000000000000 is both irrelevant and harmful, as it implies a level of precision that is not supported by the data.

I see this error of precision in estimating dates for roadmaps and requirements. A developer guesses a man-week of work, which someone translates to five days, and someone else translates to 40 hours. It shows up on a Gantt chart as 40.0 hours. But a week could be two days if the developer gets in the zone and doesn’t encounter any surprises, or it could be a month if the developer gets pulled into a dozen other problems.

I fear that we have an unrealistic expectation of precision from our project schedules. Compare the precision of development estimates to sales estimates. How precise are the numbers in your sales forecasts? What accounts will you close on what date for what revenue amount? No sales person could provide that information. Yet we somehow expect exactly that from the development schedule.

An old estimating joke is this: take the estimate, add one, and change the unit of measure. One week becomes two months; one month becomes two quarters.

A guess is a guess. Let's not attribute precision where none exists. If we track our history of guesses, we can assign a factor of accuracy. Take a look at estimates of the past to see how accurate they were and use this against your future planning. Don’t infer precision without the data to support it.