Using “Deprecation” Correctly
Many people, including programmers and project managers, use the word “deprecation” incorrectly. This can lead to confusion and even unexpected downtime, so let’s all try to use the same definition.
What is deprecation?
The stellar Oxford English Dictionary defines the verb “deprecate” this way:
- express disapproval of: what I deprecate is persistent indulgence.
- (be deprecated) (chiefly of a software feature) be usable but regarded as obsolete and best avoided, typically due to having been superseded: this feature is deprecated and will be removed in later versions | (as adjective deprecated) : avoid the deprecated <blink> element that causes text to flash on and off.
Deprecation is the moment, act, or expression of such disapproval, or as we mean it particularly in software, “the classification of a software feature as obsolete and best avoided” (again Oxford).
What is depreciation?
Sometimes deprecation and depreciation are confused (because they look nearly identical). The latter is more common in finance than technology, and it refers to the reduction in value of something over time.
What isn’t deprecation?
When a piece of software, a service, or a feature is actually taken offline, or reaches an end-of-life or end-of-support phase, this is variously called sunsetting or EOL, but it is definitely not deprecation. Deprecation should have come earlier (often months or years earlier), to warn customers and users of the impending EOL event.
An example of doing it right
In a recent blog post by Brent at Stitcher, one deprecation is described like this:
Dynamic properties are deprecated in PHP 8.2, and will throw an ErrorException in PHP 9.0.
This is a good example because it clearly separates the PHP version which marks the feature as best avoided from the future version in which the feature will no longer work at all.