4 ms·

Should software come with an expiry date?

13 points by steeleduncan 14y ago

csense 14y ago
Software should absolutely come with expiration dates, if they can be determined in advance. 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.
taeric 14y ago
This is borderline nonsensical, isn't it? Even the author points out that they have plenty of tools that are ridiculously old doing a perfectly fine job today still. That these are "unique" is more a sign of marketing and development patterns than it is that software "goes bad." Seems similar to asking if a clothes item should be labelled with a "will go out of fashion by..." date.
tmcw 14y ago
Said more or less the same in an also-bummed-out post earlier this year: http://macwright.org/2012/06/13/programming.html http://macwright.org/2012/06/13/programming.html
fastball 14y ago
Software in this regard is not different from other products - There is always risk involved. 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.
rogerbinns 14y ago
Software already comes with an expiry date. It is how long it is "supported" for. Just like with consuming food beyond its expiry, you can continue to consume software beyond its expiry, and you'll likely be just fine. But sometimes you'll get sick.

13 points by steeleduncan 14y ago

Software should absolutely come with expiration dates, if they can be determined in advance. 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.

taeric 14y ago

This is borderline nonsensical, isn't it? Even the author points out that they have plenty of tools that are ridiculously old doing a perfectly fine job today still. That these are "unique" is more a sign of marketing and development patterns than it is that software "goes bad." Seems similar to asking if a clothes item should be labelled with a "will go out of fashion by..." date.

tmcw 14y ago

Said more or less the same in an also-bummed-out post earlier this year: http://macwright.org/2012/06/13/programming.html http://macwright.org/2012/06/13/programming.html

fastball 14y ago

Software in this regard is not different from other products - There is always risk involved. 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.

rogerbinns 14y ago

Software already comes with an expiry date. It is how long it is "supported" for. Just like with consuming food beyond its expiry, you can continue to consume software beyond its expiry, and you'll likely be just fine. But sometimes you'll get sick.