Serialization is A Horcrux #
When you work on code that does something useful, there will always come a time when you have to serialize this data. And your serialization is never right the first time - there will be breaking changes.
Often, this serialization will happen by writing this data to a database. This mode of serialization is relatively easy to handle from a backwards compatibility perspective since you own all the data and can backfill away any inconsistencies at your leisure. Most importantly, the code that handles your backwards incompatibilities can eventually die.
Think now of serializing your data to a file. Perhaps you want the user to be able to download their data. The second you enable this capability, even in the smallest way, you are forever bound to handling that data well, or if you choose to ignore it, being okay with weird data inconsistencies and bugs that will plague your existence. You have to start writing migrations that will live forever, you will start making strange stylistic decisions about your code (for example, let’s not change this string, but introduce a new mapping from this string to another string) - in short, your code is now unkillable because a small part of its past lives in the serialized data exported one day.