From the Risks Digest, an excellent maxim via a post by Don Norman, Nielsen Norman Group & Prof. EE & Computer Science, Cognitive Science & Psychology, Northwestern University:
Never give an answer with more precision than is warranted.
The post continues with this example:
In the Southwest Airlines incident, why did the runway-length calculator give a precise answer when the variables entered into it were so imprecise: how wet really was the runway? Just how far along the runway will the plane actually touch down? What will be its exact speed at touchdown, its exact weight? How many seconds will it take the thrust reverser to be deployed (certainly not immediately -- 5 seconds? 10? 18?).
... Ideally show locations on a map as a smudge, the size comparable to the statistical likelihood. Why produce an exact stopping distance in feet? Why not produce a range, from one with everything working perfectly to one where, say, thrust reversers would not work at all, and all the other parameters were at their extreme worst ranges. Instead of displaying an exact position in hundredths of minutes or stopping distance to the foot (30 cm.), why not always show the ranges to be expected?
Reminds me of NapkinLookAndFeel for early UI work.
I think this maxim needs to be strenuously applied by many programmers when it comes to estimating the time needed to complete a task. Most development work I do is a collection of things I've done before to build something I've never done before. The precison for doing something new is never what I or my managers want it to be, but let's not fix things by lying to ourselves.
see also FractalDesign, CompletenessAndMaturity, CodeIsTheDesign, ImmaturityIsInevitable, PaulGrahamOnDesign, TendingSoftware, OversolvingPoorDesign
tags: ComputersAndTechnology
