Should software come with an expiry date?
slidetocode.com
slidetocode.com
There are many practical problems, however. Here are a few that come to mind:
(1) Upstream components/API's often don't have explicit end-of-life plans or expiry dates.
(2) Often, when or whether you shut down or breakingly change an API depends on business conditions that are impossible to predict in advance.
(3) If you publish an expiration date and your competitor doesn't, people might (usually mistakenly) believe their software is meant to last forever. Honesty about your product's shortcomings, while ethical, can cost sales if not everyone follows the same ethical standards. Regulation can help; nutrition information on food, for example, is federally mandated in the US to be present in a specific format. (Although I believe this only applies to food sold in interstate commerce.)
(4) A "best before" date may force a company to use resources to support a failed product. If you learn the hard way on launch day that only three people and a dog are willing to buy it, normally you would just discontinue the product and move on to something else. But if you've promised it will work until 2016, you're still going to be spending development resources supporting new OS's, library versions, upstream API changes, etc.
To use the authors analogy: You could purchase a car, and then the car dies. You will not get the money back for the car unless you have a warranty. You probably would not buy a car without a warranty, because the risk/benefit analysis is not very positive. However, you buy software without a warranty. Why? Because software has an element of risk, yes, but the risk is much less significant than the risk of purchasing a car.