I've often been at the start of a project and campaigned to have undo support baked in at the start. To me, it's not one of those features you should leave until when it's needed, as it affects the design of the entire system.
I've never managed to persuade product owners to bake it in, though - and so far every time I've pleaded to do so, they've ended up asking for it later (after swearing they'd never do so at project start).
I've considered picking designs that support undo without getting explicit approval to do so, but there's an additional complexity involved that means juniors will raise questions about the design and eventually you would have to admit 'so we can support undo', so that's not wise!
WordGrinder's data model is that a document is a Lua table (== array) of paragraphs; each paragraph is a table of words; each word is a string. This means that the data structures are all reasonably small in most common use so I can get away with O(n) insertion within them.
What I did for undo support was that I made paragraphs and words immutable; adding a word to a paragraph actually copied the paragraph, with the new one referring to the same words that were in the old one, plus the new word. Again, all quite cheap because the structures were small. But this means that I can now copy the entire document for each level in the undo stack, because I since paragraphs are immutable I can share them across multiple levels in the undo stack.
Surprisingly, it worked.
The tl;dr here is: immutable data structures are awesome, and I should totally have designed in undo right at the beginning.
Tell them it's for debugging: a runtime-reversible action log lets you track what the user did and step back while the program is still running. Even if it's never used for that, junior developers might be impressed by your forethought...
By the way, it's curious how some developers are happy to spend inordinate amounts of time building abstractions to help themselves, but are opposed to building abstractions that would help the user (like an undo architecture).
Agreed. Undo can be almost trivial if you bake in support at the start, it can become orders of magnitude harder to add later. In projects where I have any say in the matter, undo is there from day one.
To me Undo is one of those features that make a lot of sense internally because it forces a certain structure to your data. Whether you're doing it by commands or snapshots, the end result is a heavy separation of concerns that makes a product's internal architecture easier to maintain in the long run.
Having a user-facing "undo" action at that point is almost a side effect of just good internal metaphors.
