To put it bluntly, this is an ignorant response. Many systems have constraints beyond the control of the developer. It isn't an excuse to say, for example, that doing save/load from a PS2 memcard is slow and non-trivial; that's just the way it is.
A good designer will have a deep understanding of the capabilities and limitations of the medium they are working with. (Think Jonathan Ive and the countless testing they do using all sorts of different construction materials.) A poor designer will come up with a grand idea, but no idea how to implement it, and then blame the programmer if it's impossible to do.
I said in another comment that certain cases (like games) are the exception of the rule. But in context with the article, what I say stands. Implementing undo for users is fairly trivial. If it's not, their are other problems that need addressing.
I'm coming off that way, and I apologise. I wasn't clear. I believe the original article was mostly discussing these factors within the confines of web based applications, which is what my comments here have assumed. Obviously their are exceptions to the rule, and a true undo is not trivial. However, a true undo, and an undo that meets the users needs are different things entirely. While it's unfair for me to suggest that implementing undo is trivial, it's also unfair to assume that implementing undo has to be difficult.
I think we have common ground, here. If it's reasonable to put in undo (pragmatically speaking, in terms of money, time, technology, etc.) then I agree the user is better off having it than not.
A good designer will have a deep understanding of the capabilities and limitations of the medium they are working with. (Think Jonathan Ive and the countless testing they do using all sorts of different construction materials.) A poor designer will come up with a grand idea, but no idea how to implement it, and then blame the programmer if it's impossible to do.