[lpghatguy]

In my career, I've found that this problem crops up the most when a team is unable to make impactful changes to a system that they depend on. It's so much easier (and requires less collaboration and fewer approvals!) to build an abstraction over some core system than to actually fix the core system, even if fixing the core system is always the better choice.

I was very guilty of this as a young go-getter engineer! Why try to convince another team that something should be fixed if I can just paper over it?

[lostdog]

I also think the author is understating how bad the original framework was. I've seen some of these and the "itchy points" are real true problems. The team supporting the framework decides that fixing the pain won't get them promo because it doesn't show up in any metrics, and certainly they won't accept your submitted improvements. Your only choice is to wrap it.

Of course, since their thing is a framework, your wrapper must be a framework too. (Is it possible to wrap a framework into a library?)

The end of the story is even sadder. You work on your replacement and wrapper, and oh no, the framework you are wrapping has problems or slowness because of the framework it depends upon!