The main takeaway from the article is that abstractions which have become inadequate should be corrected (removed and/or replaced by adequate ones) as soon as possible. A corollary is that abstractions should be designed such that they can be replaced or removed without too much difficulty. A common problem in legacy code bases is not just that they contain many inadequate abstractions, but that the abstractions are entangled with each other such that changing one requires changing a dozen others. You start pulling at one end and eventually realize that it’s all one large Gordian knot. One thing that I learned the hard way over the years is to design abstractions as loosely coupled and as independent from each other as possible. Then it becomes more practical to replace them when needed.