The idea that removing external dependencies necessarily simplifies your code and leads to a maintainable system is a fallacy. Use external dependencies appropr

The idea that removing external dependencies necessarily simplifies your code and leads to a maintainable system is a fallacy. Use external dependencies appropriately, follow SOLID principles and a clean architecture and you can leverage the benefits of other people’s code without losing the intelligibility of your system. In the example the author gives, the real mistake is allowing the web framework to define a system that you then try to customise to produce your application. The battle is already lost because your business logic is now a dependency of someone else’s (rotting) generic web app template. This may be appropriate for you if this is a proof of concept or spike but for something with a longer lifetime, any time you save will be paid back with interest when the host framework diverges from your needs. A JSON parser is not an equivalent class of dependency if you keep it at the periphery of your system. There’s not much point in writing a JSON parser unless you have a particular requirement that cannot be satisfied by a third party library. You should be able to swap it out for a different JSON parser in a few hours. 80:20 seems like a ratio that was just pulled out of the air; I have no data to hand either but for most user applications I would suspect the real ratio is more like 99:1. Edited to add: I’m still in agreement with a lot of what the author says here, such as: evaluate your dependencies seriously, understand them, and be mindful of their impact on things like binary size.