First of all I agree with the top (currently) commenter that the examples the author gives are not really abstractions, at least not of the kind I thought this

First of all I agree with the top (currently) commenter that the examples the author gives are not really abstractions, at least not of the kind I thought this would be about. Anyway, my thoughts on the subject: Ofcourse the problems with abstractions is when they leak; when you read an unfamiliar codebase for which you do (not yet) understand the abstractions and reasons behind them, you brain will be leaking cases all around them. There are ways people try to prevent that; 4gl, xml/json ‘definitions’, DSLs etc but unless you actually deliver the ‘runtime’ or libraries (classes (sealed etc in C#) and frameworks) as binary, your new colleagues will look under the hood and probably cry until either they get it or find it is actual crap. In the end it never really works if you go broad (let too many people look under the hood) because people want to/have to break out of the abstraction and start to abuse the leaks. And then the result will become an absolute mess. I did a lot of successful projects with very high level abstractions but they all rot when another team takes over. That is normal for most code imho though; I measure success in decades not years and I have stable ancient code running in many companies/online which use the abstractions and the shielding to keep those transactions from leaking for all those years. Yes, it limits what you can do with it, but if that is a given and the business case holds up and management is not swayed by ‘but I read now we need to use something called React/Redux’ then there is a lot of mileage to be gotten out of effective abstractions.