Serialization considered harmful

The ability to serialize an object can be a very useful feature of a language or framework but there is a trap that developers often fall into when they first discover this functionality. Almost every app we ever work on requires some kind of file format to store information about the document the user is working on. So a developer will often think to themselves "This serialization stuff will save me heaps of time. I can serialize my object hierarchy with two lines of code when I need to save the document and deserialize it when I need to load the document". This way madness lies. Once you do this, your file format is completely dependent on the internal class structure. Want to change a property name or type? Bam, your file format is broken. Want to remove a property? Bam, your file format is broken. In fact, in .NET adding a new property will break your file format. Delphi is different in this respect since it will cope with adding new properties, but whether that is a good thing is open to question since it may tempt you into thinking this is a viable approach. A Delphi project I worked on used this approach for many years and it kind of worked, at the expense of being able to do any meaningful refactoring during the many years of its development. So if serialization is such a bad thing, why is it even in Delphi and .NET? Because it can be exceedingly useful. For instance, passing objects between processes, copying and pasting to the clipboard. Essentially, serialization is useful for short-lived operations. When things are written to file and we need to worry about backwards compatibility, serialization is not you friend.