Should code have an expiry date?

In a conversation with a fellow software developer, he stated that all code should have an expiry date.

I must say, I like the idea of setting an expiry date for code I write.

Maybe not the kind of expiry date the food industry uses, where an item must be consumed before a date or its unsafe to eat, but rather a "must revisit before" date

The author(s)'perceived quality of the software determines its expiry date.

Some example questions to consider:

• How stable, complete, and validated were/are the requirements (functional and non-functional)
• Was the code rushed to production? Or was it developed with care and attention to detail?
• Is it using an antiquated or experimental technology or exotic/experimental/not widely used programming language?
• Does it have tests?
• Was the code written after the tests?
• Was it reviewed and/or pair programmed?
• ...

Answers to the above example questions and others can help determine until what date code is supposed to be used. By stamping the code with an expiry date, a developer or a team makes a statement on the quality practices used to produce it.

Another question is: who should set the expiry date? The developer? The code reviewer? Some other stakeholder? A combination of all?

I must say that there is some perversion in this. The expiry date makes anyone using a piece of code after that date responsible for their actions. Like eating yogurt after the expiry date. You decide if you want to risk eating it or not.

This date should be dynamic. If the code gets revisited and/or refactored, this should have an impact on the date.

What do you think?