> So far so good, perhaps. But, by creating this new abstraction, the programmer signals to posterity that this new abstraction is “the way things should be” an

> So far so good, perhaps. But, by creating this new abstraction, the programmer signals to posterity that this new abstraction is “the way things should be” and that this new abstraction ought not to be messed with. As a result, this abstraction gets bastardized over time as maintainers of the code need to change it yet simultaneously feel compelled to preserve it. How I've been thinking about abstractions that turn bad over time is: It was likely the correct abstraction at the time it was made, given the requirements the writer had on hand. Now that the abstraction is wrong, don't muck with it. Gather the new requirements and write a v2. I think the vast majority of abstractions will go bad over time. To abstract is to generalize, and generalizations become invalid over time because the world evolves over time. It's sort of like trying to preserve a summary of a book that is continuously having new pages added and existing pages replaced.