Honestly, within a single moderately sized codebase for your average boring CRUD app, i'm not sure why you should have interfaces for everything. 99% of those

Honestly, within a single moderately sized codebase for your average boring CRUD app, i'm not sure why you should have interfaces for everything. 99% of those will never be as popular as Kubernetes, Graylog or Ghost. And it's not like introducing those interfaces wouldn't be connected to lots and lots of work: like in the case of Ghost, you cannot be a part of the crowd that suggests that ORMs are bad most of the time and then also suggest that interfaces are good and you also should abstract away the database in some other (possibly infeasible) way. It's not like you cannot do that, but you absolutely cannot do that in a reasonable amount of time. When your boss is asking you to ship features by the next tuesday, you don't even have the liberty of thinking about what is generalizable and what ever will be - you just write the implementation directly and get it done. And if you ever actually need an interface? Just extract one with your IDE. Is it all too polluted with implementation details to do that, because of the aforementioned time/resource limitations? Then simply rewrite it anew, throwing all of the gunk out. You cannot rewrite it because of its size and coupling to the rest of the system, you say? Then you don't actually need the interface - don't poke the codebase with too much refactoring, lest it fail. The point i'm making is that while most projects out there will never have the need or resources for having interfaces for everything, even the larger projects that could have them (like the example about Kubernetes), might be so complicated that introducing them might result in a lot of breakage despite your best efforts and would reflect badly upon the entire project.