It's true for the code. But not always for the system that the code becomes, or for the consequences caused by outputs of the system. Examples: Not all database migrations in production are easily undoable without impacting service. Or if the output is used to make say financial decisions, money lost on that might not be recoverable. So at least a conscious relationship to these potentials is very advantageous when making changes. And also when designing a system, try to minimize the amount of actions that are not undoable without negative side effects. An also to build systems where one can roll forward to effectively undo a change (even if one does not / cannot technically go back).