You can also rephrase that as a business concern. Instead of how ugly the code is or how challenging it is the more important factor is how long does it take t

You can also rephrase that as a business concern. Instead of how ugly the code is or how challenging it is the more important factor is how long does it take to accomplish a given change. The challenge there is if you have isolated yourself to a happy path you have no idea what the edge cases are, what the regulatory concerns are, or what prior business concerns have already been addressed. You really have no idea how long the task will take to complete or the scope of actual work. It is a big risk to leave your framework dream world and embrace reality. By living in reality I know how to account for those various concerns. I can provide a more accurate estimate of effort and still get it done 8-12x faster. You don't get better at anything by closing off reality and hiding from failure. The problem with using a bunch of unnecessary abstractions and tools is that you have to choose between two really horrid scenarios. Do you give up on speed of delivery and product quality to work within the tools in place? Or, do you account for all the business concerns and deliver quickly by creating a one-off and possibly fighting those existing tools to do it? The best way to know what to add to a project (dependencies) are those things you known you will deliberately never maintain and that require a one time configuration. For example I use a linter to check my code. It is a dependency that I never modify, I never reconfigure, I never look into its code, and I almost never update. If I were forced to peer into the code and read all about how it works and really get intimate with it I might as well just write it myself, because you will be maintaining it just the same anyways.