I agree, it's better to be pragmatic. So it's not super useful to say that LSP is about whether you're doing it right or wrong. I prefer to think of it in term

I agree, it's better to be pragmatic. So it's not super useful to say that LSP is about whether you're doing it right or wrong. I prefer to think of it in terms of making the codebase intuitive to work in. So I like to formulate it as, "You should be able to safely and fearlessly plug any subtype of a class into a method that accepts that class as an argument." This is a bit of a departure from how Liskov originally formulated things, but I think it is fair to say that it's a refinement that better captures the spirit of how she talks about it in more recent interviews. And it also captures why it's such an important principle, especially if you're working on a team: Nobody wants to get stuck working in a codebase where Widgets are partitioned into two different categories that can only be distinguished by carefully reading their implementations, according to criteria that can only be understood by carefully reading the implementations of methods that operate on Widgets. It's not wrong, per se, it's just not a working environment that any self-respecting person wants to be stuck in..