Laws of the Lazy Programmer
To recap, lazy programming is not necessarily the easiest path in the short-term. The lazy path is the most efficient in the long-term to understand, reuse, maintain, and extend. Over time, the lazy paths waste the least time, money and energy. Being perfectly lazy often requires some hard work up front to ensure these long-term goals are met.
Law: On a long enough timeline, every possibility becomes a probability.
It is important to understand both the intended longevity and the likely longevity of every action. Though every action is permanent, "longevity" is the length of time you can be reasonably held responsible for the effects of an action.
When the longevity of a product is both intended and likely to be measured in weeks, your approach should be completely different than when the longevity is expected to be measured in years. This is because on a long enough timeline, every possible event becomes a probable event.
On a brief timeline it is reasonable to expect fewer events, and so design does not need to consider as many probabilities. The total effort spent on documentation, development, and the handling of unlikely events should be lower than on a longer timeline.The total effort spent should be appropriate to the timeline.
When the law is ignored, either too much effort goes toward short-lived actions, or too little effort goes toward long-lived actions. In the first case, the waste is obvious and immediate. The second is an order of magnitude more expensive. Problems stay hidden longer and are compounded by other changes, and therefore become more complex to solve. When the same problems are considered from the beginning, you can either build resistance into the product itself, or plan a course of action should the problem arise. When problems are considered from the beginning, the design of the product allows for an efficient solution.
See also: Risk Management, Murphy's Law.